OpenEuphoria

Error Handling

• Posted by David Cuny <dcuny at LANSET.COM> Mar 17, 2001
• 649 views

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.

This is a Bad Thing, because it leads to people losing their work, or
programs stopping which could potentially recover.

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.

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