OpenEuphoria

Re: Error Handling

• Posted by Ted Fines <fines at macalester.edu> Mar 17, 2001
• 682 views

Yes!  This is probably the most needed feature in Euphoria.  I too second, 
third, etc. that.

--On Saturday, March 17, 2001 12:40:58 AM -0800 David Cuny 
<dcuny at LANSET.COM> wrote:

>
>
> 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
>
>
>
>