OpenEuphoria

Re: "safer" Euphoria

• Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Jul 13, 1998
• 495 views

Robert replied to my suggestions:

< snip (lots of stuff I agree with) >


[New Suggestion]

I've given it a bit more thought, and have a modification of my initial
suggestion. When Euphoria sees an error, I'd like it to see it:

  1. Log the error in EX.ERR
  2. Execute the global exception handler (if it exists)
  3. Optionally try to continue

The exception handler could be passed a value by Euphoria, indicating if
the error could be "recovered from". A "recoverable error" might be an
uninitialized variable, or an out of range index.

In order to continue, the exception handler would have to call a routine
that would pop up a dialog like this:


 +----------------------------------+
 |   ***  Really Bad Error ***      |
 | The program encountered a really |
 | bad error. However, it was able  |
 | to save the file to disk.        |
 |                                  |
 |  << Shut Down >>    < Ignore >   |
 +----------------------------------+

The text of the dialog could be selected by the coder, and the "Ignore"
button would be optional, (but automatically dimmed if Euphoria deemed
that the error was "unrecoverable").

I like this option a lot - it gives control to the user, but makes it
impossible to hide coding bugs.


["Expensive" Code]

> I therefore reject the notion that these checks are so
> expensive that we need a way to turn them off in shippable
> code.

I didn't mean to imply that the current tests were expensive, but that
automatically "correcting" range errors would be more expensive.

But it's obviously foolish for me to make any statements about how
"expensive", "inexpensive" or "efficient" Euphoria's code may be. 

[Debugging and Knowlegeable Users]

>On a compiler project I worked on several years ago, I deliberately
>*left in* lots of redundant debug checks and assertions in
>#ifdef code. The compiler ran 5% slower and was shipped to the
customers.
>This approach paid off in a big way. Users couldn't
>care less about the extra 5%, but they were able to report
>*meaningful* bugs back to me, which I could easily fix. Otherwise
>it could have wasted days of their time and days of my time to track
down
>the resulting bugs in the machine code. (I also had some
>extra, very expensive, checks that I only turned on for in-house
>debugging).

I agree, but suspect that one of the main reasons it worked was because
your users were Knowledgeable Programmers. They understand what happened
when your compiler spit out an error condition; they appreciate that
sending in a bug report will give them a better product. They Have A
Clue.

I would guess (and risk being Very Wrong) the typical users of Euphoria
are also mostly programmers. If a Euphoria program detects an error and
shuts down (not the same as crashing), the user will understand what has
happened.

-- David Cuny