Re: exception handler
Robert Craig wrote:
>
> I'm ready to implement the global exception handler concept.
YEAH!!! (First recorded suggestion in Sep 1999 by Pete Eberlein)
> This will give your program a chance to take some action
> when the Euphoria interpreter (or less common - translated code)
> detects a run-time error. In 2.5 your program is completely parsed
> (compiled) before any execution begins, so there isn't much
> value in being able to react to compile-time errors.
And this means that forward referencing is possible too, of course. But
that's another battle.
> The implementation of this thing probably won't be difficult,
> but I want to get the language design right.
Excellent. Fully support that approach.
> I'm assuming the following:
>
> * using routine id's you can specify one or more routines
> to receive control when a run-time error occurs. Allowing
> more than one routine would be useful for library writers
> who might want to specify a routine to clean up resources,
> locked files etc. for their library, independent of what
> the application writer wants to do in his own code.
Yes.
> * you can't resume execution. Once the crash routine(s)
> have finished, the program will terminate.
Probably. However some 'crashes' may be recoverable. Divide by
zero using input from an operator - you ask the operator for a
different value.
> * by default, the most recently specified crash routine will
> be executed first, working back to the first routine
> specified. Maybe there will be a way to change this order.
Yes.
> * your routine(s) will be called after the normal ex.err dump
> occurs, so I guess your routine(s) could look at ex.err
> in deciding what to do. If a second ex.err is necessary
> while running your routines, I'll use a different file name,
> like ex2.err or something. If your routine(s) themselves crash,
> there won't be any more calls to crash routines. That's the end.
Usable. But a formal EU-defined error data passed to the routine
would be more useful - detailing reason for crash, file name, line
number, calling stack trace(?).
> The possible uses for this have been discussed before.
> e.g.
> - cleaning up files and resources that won't automatically be
> cleaned up when the interpreter terminates your program.
>
> - the "classic" example of an editor that could save the
> user's edit buffer to disk before dying.
>
> - a server program that could send an e-mail notification
> with debug info (such as ex.err) when it dies unexpectedly
> in the middle of the night.
>
> - I suppose a program could effectively restart itself
> and keep going if a crash routine were set up that way.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
Thanks Robert. But will this significantly slow down the delivery of 2.5?
I know this enhancement is essential for quality commercial software
development, but maybe it can be added to 2.5.1, during which time
we can shake out any issues with the whatever is currently in 2.5?
--
Derek Parnell
Melbourne, Australia
|
Not Categorized, Please Help
|
|
