One of the most infuriating AppleScript errors is also one that many users see at some stage: errOSAInternalTableOverflow. It is particularly annoying because when it happens AppleScript itself is usually corrupted, so you have to close and relaunch your editor.
What does it mean, what causes it, and how can you avoid it? Apart from the first, these are not easy questions to answer.
Simply, the error means a script has too many objects to keep track of. When a script is stored, AppleScript assigns every object an ID, which is used to reconstruct references between objects when they are loaded back in. There is a maximum number of IDs available for any given store/load operation. If a script has too many objects, the ID table overflows and you get this error.
In this context, objects does not mean just variables and literal values: a simple if
statement is stored as a tree containing many objects, for example. The ID table contains all the objects required to faithfully store and restore a script.
Clearly, avoiding the error is a matter of not exceeding the ID limit. The problem, however, is that there is no simple way to look at code and accurately estimate how many objects it requires when stored — it will depend very much on what the code does.
That said, the number of lines of code can provide a rule of thumb as a starting point. If a script exceeds about 2000 lines, there is probably a reasonable chance of the error striking; it is probably safer to aim for a lower figure, perhaps 1000-1500. (And yes, there are people running scripts containing 4000+ lines; that just reinforces the point of what a crude metric this is.)
But there are other things you need to be aware of: it is possible to trigger the error with far fewer lines. This is particularly so with deeply recursive code, and deeply nested code. In such cases the error might happen not when saving the script, but when running it, because that can generate a lot more objects that need to be temporarily stored.
Also, when you put a script in debugging mode, Script Debugger incorporates extra instrumentation code in the script — that’s how debugging works. That can mean a script compiles and works fine when not in debugging mode, but generates an error when debugging is turned on.
(If you save a script in Script Debugger 8 with debugging on, the code is saved to file without debugging instrumentation code. In previous versions this was not the case, to support external debugging.)
So when you scripts start getting long, it is a good idea to start thinking about breaking them up, putting sections in script libraries. The earlier you do this, often the easier it is.
And if you have a script that is too long, don’t just trim to the point it starts working again — allow a bit of run-time margin. In the worst case — perhaps you need a quick temporary fix — keep in mind that saving code as run-only means fewer objects need to be stored, which can give you more overhead at run-time.
But remember, if and when you get a table overflow error, save your code immediately, then quit and relaunch Script Debugger. (The same goes for any other script editor.) And if you start seeing any other oddities, consider doing a full system restart.