Details on caught errors
benr_mc at cogapp.com
Mon Sep 9 09:13:00 CDT 2002
Documentation for "catch errorParameter" says:
When one of the statements in a try control structure causes
an execution error, the errorParameter is set to the error
string, and the statements after the catch keyword are
executed. If Revolution generates the error (for example, an
execution error from a built-in command), the errorParameter
is a positive number. An error string can also be returned
from a handler by the throw keyword.
Documentation for "errorDialog errorContents" says:
The errorContents specifies the details of the problem that
caused the errorDialog message to be sent, and consists of
1. Information about the statement that caused the error
2. Information about the handler where the error occurred
3. Information about the object whose script the handler is in
A list of possible execution errors is contained in the
³cErrorsList² property of the first card of the stack
³revErrorDisplay². You can view the list with the following
answer the cErrorsList of card 1 of stack "revErrorDisplay"
Note: The exact format of the errorContents may change
from release to release.
* using errorDialog, the errorContents appears to consist of multiples of
three lines (not three); this seems to correspond to what is described in
the documentation, repeated for each point on the calling chain. Each line
consists of three comma-separated integers; all but the first line then have
a string following these integers, identifying a handler or object.
* using catch we seem to get three comma-separated integers in the
errorParameter (not one) if the statement causing the error is within the
try/catch construct. Repeating the same code (after going back to idle)
gives increasing numbers of lines in errorParameter, with the new
information being appended to the end.
* using catch, if the error is in a handler invoked within the try/catch
construct, rather than directly inline, then we get something more like the
parameter to errorDialog, and it is not affected by previous errors.
Of the three integers, it looks like the second in each case is a line
number in an object's script. The first integer on the first line appears
to index into the error list described in the documentation.
* what is the interpretation of the third integer on each line?
* what is the interpration of the first integer, on each line after the
* is it a bug that when catch catches an error inline, the error results
are accumulated? Is there a workaround?
The documentation, combined with experimentation, gives a lot of clues that
go quite a long way in interpreting this; but I think the documentation does
contain some errors in this area, and could do with some clarification.
Ben Rubinstein | Email: benr_mc at cogapp.com
Cognitive Applications Ltd | Phone: +44 (0)1273-821600
http://www.cogapp.com | Fax : +44 (0)1273-728866
More information about the use-livecode