Re: exception handler
Robert Craig wrote:
>
> I'm ready to implement the global exception handler concept.
> 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.
The crash routine shyould recieve an error code(like EC_DIV_BY_0), the
error message(like "attempt to divide by 0")
>
> * you can't resume execution. Once the crash routine(s)
> have finished, the program will terminate.
There should be a way to resume execution(like a crash routine returning a
certain value, for example after asking the user whether to try to continue)
This should only be able to happen with the first crash routine
>
> * 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
> 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.
If a crash routine itself crashes, Euphoria should write the error to ex_#.err
(or if another neme was set, like crash.abc, to crash_#.abc)
and continue with the next crash routine. This would make sure every crash
routine runs.
>
> 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.
This woulld be VERY helpful!
Now if only Euphoria could prevent data loss caused by other problems
(like power outages,computer catching fire, cats unplugging the computer)...
>
> - 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.
This would definatly be useful for my webserver program.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
|
Not Categorized, Please Help
|
|
