Re: exception handler
On Mon, 23 Aug 2004 18:35:51 -0700, Robert Craig
<guest at RapidEuphoria.com> wrote:
>I'm ready to implement the global exception handler concept.
I'll tell you what I know about x86 support for exception handlers, of
which there are two types:
A 'final exception handler' has only one instance, and if you attempt
to define a second, it simply overwrites all evidence that the
previous handler ever existed. While it is technically possible to
resume from this type of handler, that is not why it exists.
The other type is 'structured exception handling', which allows nested
try/catch blocks and is designed to allow a program to recover and
continue, and allow 'throw' to act as a sort of goto statement. The
main requirement is to define a 'safe place' for processing to resume,
since you cannot eg resume on a divide-by-zero error - if it was 1/X
then you _might_ be able to set X non-zero, but if F() has returned
zero in 1/F() there is no 'safe place' to resume. This type of handler
is strongly tied to the call/return stack, and will automatically
reset the stack pointer when handling an exception from a nested call,
etc.
It sounds to me that you might want to implement the equivalent of a
final exception handler first and leave structured/resuming for later.
>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.
>The implementation of this thing probably won't be difficult,
>but I want to get the language design right.
>
>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.
>
While you can use routine_id for the final exception handler, I think
you should use try... catch... end try blocks, where the end try
statement defines the 'safe place' if the handler attempts to continue
execution.
> * you can't resume execution. Once the crash routine(s)
> have finished, the program will terminate.
>
As above, that is what a final exception handler should do.
> * 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.
>
> * your routine(s) will be called after the normal ex.err dump
OK, no real preference here.
> occurs, so I guess your routine(s) could look at ex.err
Oh dear. I guess that means we'll need a library specifically for
library exception handlers...
> 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.
I vote against that. If the program's exception handler crashes, that
should be left in ex.err and be the first thing the programmer has to
fix. The original problem will have to be reproduced and the ex.err
for that recreated. Besides, after fixing one, the line numbers for
the other problem may be all wrong.
You should probably zero the internal copy of that routine_id before
calling it, to reduce the chance of an infinite loop.
>
>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.
How?
>
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
>
|
Not Categorized, Please Help
|
|
