Re: Error Handling

new topic     » goto parent     » topic index » view thread      » older message » newer message

Robert Craig wrote:

First, thanks for considering the idea. I'm not trying to get into an
extended debate, I just thought I'd hit on a couple of points. Feel free not
to reply. smile


> You can control exactly what appears
> on your screen when an error occurs.

Euphoria's current behavior is to halt in a controlled manner, and offer the
option for a traceback and an error message. This is great for debugging.
And yes, I know that it can all be suppressed.

I'm glad these options are available. It would be nice if, under Windows,
the error message appeared in a message box dialog instead of the console. A
console window is a disconcerting thing to show a user!

But I'm getting off track.

The point I was trying to make was that there are quite a number of features
in Euphoria that support trapping and tracing run-time errors. In contrast,
there aren't any that support *recovering* from a run-time error.

Unlike many other interpreted languages, Euphoria tends to be very strict
about what it allows, so Euphoria is likely to catch an error before it
trashes the code.

And unlike many other languages, Euphoria only passes by value, so errors in
routines tend to be isolated (although globals and module-level varibles can
still be accessed).

I agree with your reservations - I'm not entirely convinced that Euphoria
should try to *recover* from errors. Then again, I'm not entirely convinced
it's a bad idea.


> "program X has attempted an illegal operation
> and will be shut down".

Apples and oranges. I've gotten plenty of 'illegal operation' errors in
Euphoria. It's not C++ or Euphoria's fault; it's just the nature of
interfacing with Windows. Access non-allocated memory and go to jail.

I'm talking about the sort of thing error that Euphoria currently traps.
Like Java, Python and QBasic, Euphoria is interpreted. It's not at the mercy
of blind machine code instructions. It can trap errors that shut down
compiled languages.

No, there isn't any magic. The best way to ensure programs not failing code
defensively, and to test, test, and test some more. Still, any tool that
makes my code a bit more bulletproof seems worth considering.

Thanks!

-- David Cuny

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu