Re: Error Handling
----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Sent: Saturday, March 17, 2001 5:26 PM
Subject: Re: Error Handling
> 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.
My suggestion is not to put user input in a type-checked variable
immediately. Instead, check it first (using the type-check routine as a
function) and if it returns 0, then ask the user to re-enter the value. If
you have the program ask the user to re-enter the value every time there's a
type-check error, what happens when the user entered a perfectly valid value
and it's your program that messed up. And what if you made the form that
asked for the value disappear before the error so there's no way to reenter
the value?
>
> 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
|
Not Categorized, Please Help
|
|
