OpenEuphoria

Re: Error Handling

• Posted by Irv Mullins <irvm at ellijay.com> Mar 17, 2001
• 661 views

From: David Cuny <dcuny at LANSET.COM>
...
> 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:
>
> 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:
>
> 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?

That's what I always wished type() could do;  instead of just
unceremoniously ending the program;
you would have the option to fix the problem and continue on if you wished:

A simple example:
type hour(object x)
if x < 0 and x < 25 then return x
else
-- a routine to do what you want, for example, show a message and ask user
to repeat
-- his entry with a valid hour.
-- or, just set x to a safe value, etc.

Using type in this way would be more versatile than an ON_ERROR, which has
to be
changed frequently to reflect the possible error/recovery conditions. Type
would also
be able to catch and differentiate between possible mutliple errors:

type hours(object x)
if hours < 0 or hours > 40 then ....fix'em or ask for user to do so
else return hours
...
type rate (object x)
if not atom(x) then ....error routine
elsif x < minimum_wage then ...error routine, or set x = minimum_wage
elsif x > bosses_wage then ...you're fired routine
else return x
..
function payamount (hours worked, rate dollars)

This function would be assured that both values passed to it were ok,
and any variables defined as hours or rate would be protected automatically
no matter where in the program they appeared.

Regards,
Irv