Yes, I see what you are doing here, but think of the cost.
EVERY call to a handler would have to be called from within a try block
that appends the handler name to the error message. This would make
the script almost unreadable.
I don't see what you're saying here. The only calls to handlers that would have to be in try blocks are the ones you want to track the source of the error.
In one script where I do this there's only a few handlers where I need that feedback.
Each handler doesn't need it's own try block. If you had a try block for every handler call, you would already know which handler tripped the error. Here you can have multiple handler calls in a single tell block and get the info about which handler tripped
the error.
This might work to debug a problem during development, but beyond that
I think it would be unworkable. I need to know the source of un-programmed
errors in a finished product.
I use SD, so I don't need this for development. :)
You could also pass the un-programmed error without change, and store the handler name in a script property.
Basically the first line in every handler sets the property to the handler's name. When there's an error trapped, you have the name of the handler in the property.
(I prefer using the error attributes because in a complex script where handlers call handlers, this gets a bit more complex. You need to reset the property after handler calls, or set the handler property to a list, and add the current handler to the end,
and resetting at some point.)
This seems not to be possible, but if Apple is looking for ways to improve
AppleScript, returning the name of the source handler of an error
would be worth its weight in gold.
No argument there. In the meantime there are things we scripters can do that workaround not having that.
|