Re: Error Handling
----- Original Message -----
From: "David Cuny" <dcuny at LANSET.COM>
To: "EUforum" <EUforum at topica.com>
Sent: Saturday, March 17, 2001 3:40 AM
Subject: Error Handling
> I had written a simple Windows game, and was showing it off to various
> people. Naturally, it crashed and burned - especially on NT machines. Up
> popped the console, spewing a traceback, and an EX.ERR appeard on the
> desktop. While this information was useful to me, it's not the sort of
thing
> I'd want the user to ever see.
>
> I've written another small Euphoria program that will be used in front of
my
> entire division. I'd hate to see it go down in flames in front of all
those
> people. Naturally, I've checked it for errors, but I'm no Knuth - there
are
> bound to be error lurking in the code.
>
> For this reason, I never use Euphoria's custom types. It's akin to using
> ASSERTS in C - great for testing code, but you don't want them in the
> release code. Euphoria has all these great tools for catching bugs - but
> nothing for recovering from them at runtime.
I agree, except I don't think recovering from such an error at runtime is
such a good idea. In my opinion, asserts and other similar debugging
techniques should be used to find errors when developing the program, and
then turned off once the program is supposed to be stable. In Euphoria, you
could still use the custom types then just do without type_check when the
program is suppsoed to be stable.
> This is a Bad Thing, because it leads to people losing their work, or
> programs stopping which could potentially recover.
If the program fails on an assertion or type_check, it's probably
sufficiently messed up to have little chance for a simple recovery.
Meanwhile, adding such error handling would clutter up the language and the
code, and it would be very difficult to recover. However, what could be done
I suppose is to write the value of every variable and the entire call stack
to a file which one could then debug and extract any recoverable data from i
t. Perhaps a debugging version of the interpreter could write a trace file
of every statement so you can debug first using type checks etc., then run
it through with the trace file so if it crashes you can find out exactly
where and why, then when you're certain everything is fixed disable the type
checks and the trace file.
> In contrast, almost all the 'modern' languages (such as Java or Python)
have
> some sort of try/fail mechanism. Heck, even QBasic has an ON ERROR
> statement. While I've never really been a fan of this sort of thing, it
> serves an important function: it makes better code.
The only reason I've ever used the On Error in basic, or exceptions in Java
are for unexpected errors. For example, I use On Error in some of my Basic
programs in case it can't open a file, for example (since Basic doesn't
return -1 if there's a problem opening a file.) In Java, I'd use exceptions.
I prefer either using exceptions or error codes, since then you can tell
exactly what failed and sometimes why. In my opinion, they're both cleaner.
> In the past, I've lobbied for something like this:
>
> crash_routine = routine_id("MyCrashRoutine")
>
> This way, you could at least save the user's valuable data, so they don't
> lose all their work.
>
> I still think this sort of thing would be good, but I think we can do
> better. Imagine that we had a 'on error' routine for functions and
> procedures. If a 'fatal' error is encountered, Euphoria branches to that
> clause:
>
> function my_function
> -- code goes here
> on error do
> -- recover from error
> end procedure
>
> If there were no recovery routine for the current routine, Euphoria pop
it's
> return stack until it encountered one. So if there were no recovery
routines
> at all, it would simply fail as it currently does. If you wanted to be
lazy
> (like me), you could just put a single recovery routine in the top level
> procedure:
>
> procedure main()
> -- code goes here
>
> on error do
> -- save the data file and shut down
>
> end procedure
>
> Unlike crash_routine, the 'on error' clause would allow the routine to
> recover from the error. This means that programs wouldn't come crashing to
a
> halt. You could control exactly how fine a level of control you wanted.
>
> Comments?
>
> -- David Cuny
I think that generally, fatal errors are very difficult to recover from -
especially if you don't know where the program failed or why. The fatal
error might be due to a mistake many statements back, and that mistake might
have messed up the data so that it is impossible to recover from it.
Jeff Fielding
|
Not Categorized, Please Help
|
|
