OpenEuphoria

Re: "safer" Euphoria

• Posted by David Cuny <dcuny at LANSET.COM> Jul 13, 1998
• 503 views

Irv wrote:

> [The user environment] is different. The end user
> flails away at the keyboard and mouse, entering
>text where numbers should go, and dividing monthly
>pay by Fred. They also occasionally delete files at
>random "to clean up their disk", and then complain
>that your program "won't work". These actions are
>rather hard to predict.


Yes, I agree. But see Alan Cooper's (software interface guru) article at:

    http://www.cooper.com/articles/vbpj_ban_the_bomb.html

why "Programs should not have error messages. None. Not a single one. Ever."

Besides, these errors are not *user* errors: they are errors on the part of
the coder.

>Failsafe

In the cases that I'm talking about, there is no reason to assume that the
data is bad. Euphoria has merely determined that the instruction that it has
been requested to do -at the coder's request - is not legal. As a result, it
will *punish* the user of the code by shutting down, and the user will be
that much less happy with my program.

In a design environment, this is *excellent* behavior. In the end user
environment, it's probably *not* what you want to have happen.

With compiled code, it would be a different matter - the code is off and
running goodness-knows-what, stomping over precious memory and files. You
want the process shut down cold, before it can do any more damage, and bring
down the OS.

But Euphoria is *not* crashing - we're talking about a controlled shutdown
at this point. It's a Design Feature. Euphoria *knows* that the value is
bad, and can probably make a reasonable guess as to what an acceptable value
might be. The kind of errors I'm talking about include:

    - Asking for a slice beyond the length of a sequence
    - Using a variable before it's been initialized
    - Moving the cursor off the screen
    - Selecting an illegal color

Up to the point of the "bad" instruction (which has not yet been executed),
there is no reason to assume that the data is bad. So we have every reason
to think that it can be saved.

But beyond that, since Euphoria can make a good guess what the value *might*
be, why not let it? Obviously, it's designed otherwise, for compelling
reason:

1. Because it's an error. It's clearly in the best interest of the coder to
know where the program went wrong, but it's not so clear that bringing the
code to a halt is in the best interest in the user.

2. Because bad results will destroy the data. Possibly, but not probably.
Most of the bugs that I get in my code are sequence range errors. Nine times
out of ten, Euphoria could substitute a legal value, and the code would
continue just fine, and just fall thought at another test. In the rare cases
where it would lead to a cascade of errors, it would be clearly obvious when
it popped up error after error.

3. Because it encourages bad programming practice. If the error was handled
invisibly, I might accept that. But ominous error messages popping up are
sort of hard to hide from the end user.

I'm not advocating making the error checking any less rigorous than it is
now - only that the end user be given the option to attempt to continue past
the error. If it bombs, fine. But chances are, it won't - and the coder will
still get an error report telling exactly what went wrong. So everybody's
happy.

OK, so maybe only just me. 

-- David Cuny