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.
Sound mostly good...
I'm not going to get into the "but why can't it do this" argument,
especially asking why it can't recover to a certain point, and
continue operating without a crash.
I'd just ask that you implement it in such a way that it can be
extended, later in the piece....
Now, critique:
If it's a handler, shouldn't it be able to continue (Definition)?
Maybe it should have a different name if it can't resume.... crash
cleanup?
> * 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.
How would you define which cleanup routines handle which code? File
level, routine level? There isn't much delineation of libraries or
packages in Euphoria at the moment... it's only a file-level thing.
One thing, is - what stops the programmer from trying to continue
indefinitely in the cleanup routine(s)?
So, what arguments are the cleanup routines going to take? What sort
of information will a cleanup routine need? Seeing as routine_id is
such a generic concept, and seeing as there is a possible problem with
cleanup routines continuing too long, maybe it should have it's own
syntax?
> * you can't resume execution. Once the crash routine(s)
> have finished, the program will terminate.
Hmmm, makes things simpler, but it's limiting - all the languages I've
seen with exceptions (catch-throw) allow continuing operation. I guess
you have your reasons - but some cleanup is better than no cleanup.
If it's extensible, so that if you change your mind down the track
change is easier - that'd be a plus.
> * 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.
That's fine 
> * 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.
well ex stands for execution, I guess.... how about clean.err?
> 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.
Yup, sounds good
> - the "classic" example of an editor that could save the
> user's edit buffer to disk before dying.
Yup, sounds good - or saves the preferences back to disk <-- I want
this - damn you MEdit and your scroll wheel crashes.
> - 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.
Yup sounds good.
> - I suppose a program could effectively restart itself
> and keep going if a crash routine were set up that way.
Now, what are the limits of the cleanup routine? I ask again, what
stops a programmer trying to turn the cleanup routine into a
continue-type handler?
P.S. How about setting up a structured forum, that could tabulate
these ideas effectively, as well as for any more decisions you want
our input on. You could make it a programming competition to develop
one
--
MrTrick
|
Not Categorized, Please Help
|
|
