Gregg: > But is that feasible, and what would we have to give up in return?
I hope it is, and I hope nothing at all. You make a series of absolutely spot on and valid points about the need to write defensive code, and add our own industrial strength error checking and recovery. I agree completely. But (isn't there always a but?), the current Rebol error reporting is barely adequate as a hint about where an error is. That works fine if the error is around about the code I'm working on. But if I've screwed up and the error floats a long way down stream before exploding, I'm left trashing a haystack to find that bent needle. I'm happy to leave it to Carl to come up with something better. And I'm sure if he puts his mind to it, he'll come up with something elegant and succinct. When I get an error, I want debug information, lots of it. Let me throw in a few ideas for debugging that I would like to have. Anyone who can write these as mezzanine functions will be a hero in my eyes. -- Much better context on the error. How about the last 50 words in the "near" statement. -- Debug mode that, on error, will show the last n-teen words modified, like: mycounter <== 4 myblock <== append now/precise -- Silent trace -- trace is on but displays no output unless there is an untrapped error. Then it displays the last n-teen operations. Right now, trace is too verbose to be any use. -- I'd be happy for there to be a debug version of Rebol. Maybe it'd be twice the size of the production release. But it'd be chock full of instrumentation to check. That way, if we do lose some speed, it'd be only during development against that version. Trusted, live, code would run most of the time against the slick Rebol executable. Sunanda. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
