Re: Error Handling
- Posted by David Cuny <dcuny at LANSET.COM> Mar 17, 2001
- 727 views
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. > 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