Details on caught errors

[Ben Rubinstein]

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
    three lines:
        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


and adds:
    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
    statement:
    
      answer the cErrorsList of card 1 of stack "revErrorDisplay"
    
      Note:  The exact format of the errorContents may change
      from release to release.


In tests, 

* 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.


Some questions:
    * what is the interpretation of the third integer on each line?
    
    * what is the interpration of the first integer, on each line after the
first?
    
    * 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