Format of thrown errors; IDE error integration

[MisterX]

> As you can see, I produced this in MetaCard instead of 
> Revolution, since 
> the error codes and messages are easier to access from MC.

Jacky,

I've been thinking of this for so long... Finally made a working "try-based"
debugger this week and your message drops in the list while im looking at
what each of those items meant! But this is just a bit of info I hadn't gone
to dig yet (other than for display/linking) and I thank you for illuminating
the items in it!!! You're the goddess of the Revolution ;))

It's about time someone documented it too I might add, although I had hoped
it would come from the source for the best... Did I ever requested it on the
list just once (after 3 i usually give up and just wait it comes up
again...)? Now that I need it, you magically make it come black on white!
What an insight!!!

Here's why im so excited! Im just so impatient to release TAOO right now, my
fingers can't type straight!!! In a situation reversal, Im playing piano no
probs now even blind and the rythm is coming smoothly! Too much!!! It's a
great time for me! Things work more and more by themselves... Alas not
everything in life - too keep the challenge there ;)! 

I had to build an alternative GUI Geometry management strategy from RunRevs.
Which is called MagicGM or MGM (just a project-code name - Archimedes sounds
more appropriate for a TAOO Agent stack.) 

So the MagicGM has a bug reporter built-in to track errors because im barred
from the debugger or crash happens. It has a somewhat better approach to
find the location of the error than the debugger whithout the "in script
tracing" which I dont really want to rewrite. I hadn't yet looked at what
the errormessage/object that were in MC (despite having rewriten most of the
script and error handling in MC long ago) or even started looking if it
still exists in RR. The mail list/bugzilla request was sure to come up
again! 

So this log of errors I generated came out like an extended error bug trace
which is totally surprising - pleasant surprise that my code is working as
expected too without trying!!! 

What an irony! Without trying!

What's the penalty for using the try statement? 

10-15% in a millisecond counted loopX1000000 for a get statement - with a
catch statement it's an even gamble (same times usually)... With error
processing a bit more depending on the trace information you need ...

Time to process a real bug: minutes? Hours? 
It's better to catch bugs before they catch you!

You get the picture... My problem was compounded that debugging with the
revdebugger was an instant crash. So OK, no rant, DIY (do it yourself). Do
it right... This is a major number of try statements... But the granularity
of the errors is what makes it interesting... 

The result is not yet as cool as the error display from RR GUI wise -
granted, (which is totally well done (except for the scrolling or (cough,
cough) GM). Im jubilating because I got it without trying! The misterious
path of least resistance I guess ;)

OK, how does the extra debugging info work?

In the magicGM (soon to be released...), i trap the resizestack handler, or
a control in a stack (like a slider) calls some magicGM scripts. Every
script that does a move on a control, does a loop for each object and
"tries" to set each's prop to a value. If not, it returns an error log.
Since the script that sent the "doresize" script also tries, it's get a
result, plus it's errors. So the errors get "compounded" sort of via the
calls. at the end you get a nice list of offenses to the system but the
system doesn't crash or stop... And no reverror interuptions unless
required! 

Im sure, you (the resourceful reader) will mix-in Jacky's great information
along. Let's see who gets a cool bugInspector going first! i see RunRev as a
sort of OS for my objects!!!
 --

The result is that you get a clear path of the message that errored. From
the calling script (from where bad data could have come from) to the
faulting script (that had bad-data indigestion). 

Anyone up for it? :) I have a dumb textual palette called insithiously the
TAOODebug palette/stack to display, scroll around these errors. 

Sometimes, going your own route, can yield different inopinated results in
TAOO ;)

Anyway, im trying to do some releases this weekend so hopefully you'll see
the result.

cheers
Xavier


> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com 
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of 
> J. Landman Gay
> Sent: Friday, April 29, 2005 20:29
> To: How to use Revolution
> Subject: Re: Format of thrown errors; IDE error integration
> 
> On 4/29/05 11:46 AM, Dar Scott wrote:
> 
> > What is the format of thrown errors? How do I add to the error-code 
> > list?
> 
> Some of it is in the docs under "errorDialog":
> 
> > 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"
> 
> You should be able to add to this list by altering that card property.
> 
> The format is in the form of 3 comma-delimited items, with a 
> possible fourth item, for example:
> 
> 573,45,5,sor
> 
> I got this error by typing "sor" into the message box, for 
> which there was no equivalent handler.
> 
> Item 1 is the error ID, which corresponds to a line number in 
> the errors list stored in the revErrorDisplay stack. You'd 
> grab this line in the errors list to display the text 
> description of the error, which in this case is "can't find handler".
> 
> Item 2 is the line number of the line in the script that errored.
> 
> Item 3 is the token that errored in that line.
> 
> The fourth item, if there is one, can be the value sent to 
> the handler, the object that contains the handler, or the 
> name of the message passed to it. Since each error can 
> produce several lines of error code messages, the fourth item 
> varies if it exists at all. The "sor" error I generated 
> actually produced all these lines:
> 
> 
> 573,45,5,sor
> 253,41,1
> 253,40,1
> 241,40,1,returnInField
> 353,0,0,field id 1002 of card id 1001 of stack "Message Box" 
> of stack "/Applications/MetaCard/MetaCard 2.6.1/mctools.mc"
> 
> 
> As you can see, I produced this in MetaCard instead of 
> Revolution, since 
> the error codes and messages are easier to access from MC.
> 
> -- 
> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>