On-line error parsing tool

[Richard Gaskin]

Mark Schonewille wrote:
> Once in a while, you may run into a less-than-obvious problem, while  
> programming in Revolution. In these cases, you might see an error  
> message of the form (the code may consist of many lines):
> 
> 91,7,11,Example
> 568,7,1,Click Me
> 
> which means:
> 
> Type: Chunk (can't find stack)
> Object name: Button
> Line:(row 7 col 11)
> Hint: Example
> 
> Type: start (can't find object)
> Object name: Button
> Line:(row 7 col 1)
> Hint: Click Me
> 
> If you have no idea what causes the error, it may be useful to be able  
> to parse the error.

Unfortunately, the engine lies.

Or more politely, it uses a mysterious logic. ;)

The error info passed with the errorDialog message might appear to be a 
straightforward set of four-item lines, with two exceptions:

1. Usually the first two lines have only three items.
2. Every third line after those is junk (or is using some mysterious 
logic that eludes me).

The example below was generated by a test stack I built a couple days 
ago while updating my own custom Execution Error dialog.  In that test 
stack I have a button with a mouseUp handler that calls "DoSomething", 
which is defined in the card script and in turn calls "doSomethingElse", 
which is defined in the stack script which calls "DoX", which is also in 
the stack script and is simply:

  on DoX
    get 1+x
  end DoX

Since "x" isn't defined it generates an error, and having all those 
handlers calling one another gives me error data that looks like this 
(the line numbers at the front of each line aren't part of the error 
info, added by me here for clarity):

1  395,8,7
2  223,8,1
3  241,8,1,DoX
4  353,0,0,stack "/Applications/MetaCard/_testers/error_test.rev"
5  573,3,1,DoX
6  241,3,1,DoSomethingElse
7  353,0,0,stack "/Applications/MetaCard/_testers/error_test.rev"
8  573,4,1,doSomethingElse
9  241,4,1,DoSomething
10 353,0,0,card id 1002 of stack 
"/Applications/MetaCard/_testers/error_test.rev"
11 573,8,1,DoSomething
12 241,8,1,mouseUp
13 353,0,0,button id 1003 of card id 1002 of stack 
"/Applications/MetaCard/_testers/error_test.rev"

The first two lines, while lacking an object reference, contain useful 
stuff.  For example, line 1 refers to error #395, which is: "Operators 
+: error in right operand" -- describing the error exactly.   The second 
item in that line refers to the script line which failed, and the third 
item is the character offset to the erroneous token.  So far so good.

In line 2 we have a reference to this error message, a more general 
explanation of the issue:  "get: error in expression".  Again, 
appropriate and helpful, and the second and third items accurately refer 
to the script line and character offset of the offending statement.

Line 3 gives us the name of the handler which failed, with error 
description 241 being simply "Handler: error in statement".

Line 4 gives us the errorObject, the long ID of the object which 
contains the failing statement. Error description #353 is simply "Object 
Name:", and apparently that line is used only to convey the failing 
object.  Because that line is used only to convey the error object, it 
doesn't contain script line and character offsets.  Again, so far so good.

Then we get to line 5, which is FUBAR.

This line refers to error #573, which has this description:  "Handler: 
can't find handler".  That's not exactly true, since all handlers called 
are defined and in the message path. If we were to parse the lines of 
the error info as though they were all meaningful (as I used to do 
before revising my Execution Error dialog the other day), one might 
think that somehow a handler is either undefined or fell out of the 
message path.  Since I use a lot of libraries and backscripts, this 
approach turned out to be a time-wasting hunt for red herrings.

I've since revised my errorDialog handler to skip any line immediately 
following the one starting with "353,", since the offsets and handler 
name there are redundant anyway and the error number inaccurately 
describes what's happening.

The good news is that once you skip such lines, you'll wind up with a 
rather tidy and useful collection of data describing the full calling 
chain that led to the error.

If anyone know why the engine generates that line immediately following 
the one with the error object, and can find it useful, I'd love to learn.



The next question one might have is "Where did you get that list of 
error descriptions?"

It's hard to get to in the Rev IDE, but you'll find it in a custom 
property named cErrorsList of stack "revErrorReport" of mainstack 
"revStandaloneSettings".  (In MetaCard they're in a hidden field named 
"Messages" in the "Execution Error" stack).

The property contents are simply a return-delimited list, in which each 
line number corresponds to the error number which is the first item in 
each line of the argument passed with the errorDialog message.



 > If you would like to build this feature into your own stacks, Economy-
 > x-Talk has a shareware library available that will allow you to do so.
 > This library can be downloaded at 
<http://economy-x-talk.com/developer.html>

Unless you have a lot of time on your hands to be mucking around with 
this stuff, I would recommend using Mark's library.  It'll keep you from 
  pulling your hair out, and save you as much time as hair.

I've had the pleasure of hiring Mark to write some code for one of the 
products I manage, and I'm looking forward to using him again.  He 
writes solid code, well commented (but not distractingly over-commented) 
and in a readable style, and his turnaround time is as excellent as his 
rate.  If you need a pinch-hitter on your project, or are looking for a 
useful library, I can't recommend Mark's work strongly enough.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com