Re: crash_message
----- Original Message -----
From: Boehme, Gabriel <gboehme at POSTOFFICE.MUSICLAND.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Friday, September 03, 1999 12:17 PM
Subject: Re: crash_message
> Interesting. Nobody seems to want to respond to the points I raised
earlier.
Seems to me it's simple, what to do next depends on what the error handler
tells the program to do. Any error prior to the end of the error handler
means the execution passes on to the next error handler in the chain. If the
an error is not processed by a handler, it drops to the next handler too. If
the error isn't cleared, it drops to the next handler, so you have the
ability to save vars in your handler and then drop the error onto Eu and let
the oem handler deal with cleaning up the mess as it does now: closeing
files, deallocating memory, etc. An error in a procedure not registered as
an error handler gets you a trip to the top of the error handler chain, but
an error within the error handler chain drops execution to the next handler.
Registering a handler could be as simple as a reserved word for the handler
name. When "including" code with handlers, the handlers are stacked by Eu in
the order they are "included". It gets mildly complicated in coding Eu only
if you want to be really flexible and be able to declare a handler as global
vs private to a *.e file, but i am sure Rob, Junko, David, and Ralf can
figure it out.. 
Since there is a limit to the number of included files,
multiple handler chains for private handlers isn't out of the question.
Remember, we have an interpreter here, take advantage of that, Eu can be
"smarter" than our code, it *is* in charge of running it.
> Well, I suppose it's a lot easier to argue nebulous conceptual ideas than
it
> is to actually come up with specific, detailed solutions about how this
idea
> could work within the language.
>
> In addition to the points I raised below, here's another one: if we *do*
add
> handling for specific error codes, and we *do* want to somehow continue
> running, how do we re-enter the program?
>From the error, do a "gosub next error handler" ( which, from within the
program, would be the top of the error handler chain, while from within the
error handler stack, it would be the next handler ) and then a "return from
gosub" to get to the next line in the program, or "pop return" from stack
and discard it, then "goto" someplace valid ( prolly safest at this point to
only goto ( pronounced like "call" or "execute" or "resume at" ) procedures
or functions ). By "gosub next error handler", you automatically drop to the
next error handler if your handler has an error, or doesn't clear the error,
or has no place declared to resume program execution. If the error is
cleared, and you chose to "return" to your code, you pop back up thru the
gosubs, and eventually the interpreter lands you at the line after the line
which caused the error, where you can test for that -1 in error[1] if you
want, and look at error[2] for more details, or whatever, etc..
> Do we explicitly execute something
> from our crash routine, or does the program invisibly return to re-execute
> the statement which originally caused the crash?
That's up to you. In a way, getting/testing a -1 when opening a file is an
error handler, so you'd do whatever is appropriate for what caused the
error. Personally, i'd return from the handler with a object/sequence
denoting how it was handled, and then do whatever, like you
handle/don't_handle that -1 now. If execution doesn't return, then either
there was an error in your handler or you didn't handle that error, and Eu
has dropped to the next handler and it runs like it does now.
> I suppose Rob could make the error types more precise. He could probably
> also send the routine an additional sequence value containing whatever
> variables were involved in the error, but I'm not sure what that would
> necessarily gain us. Either way, this is a *lot* of additional work for
Rob
> to do in order to add this capability to the language.
Maybe not really, it will may shift the point where in the interpreter he
determines what error msg to print out though. Having a table of the error
codes and types does not mean you must write code for each possible error.
Write the code for the *one or x* you are concerned with, the others you do
nothing with, so they are not cleared, and so they drop to the next error
handler. How?, simple, since Eu is interpreted, when Eu sees the "return" or
"goto" ( pronounced like "procedure/function call" ) at the end of your
error handler, it checks the original error flag/data/sequence/whatever , if
it is not cleared then Eu passes over it to the next error handler with the
original error data. David would just test for ( error != null ) then
DumpVarListToFile, and do nothing else.
> Now, I *know* that David Cuny's original request was merely for a sort of
> "shutdown" routine, which would quickly save data in the event of the
crash.
And it's a great idea, imho. But then, i'd applaud getting a "goto" also....
> He wouldn't really care *what* kind of error it was, so long as his data
> could be saved. But it seems to me that having this "crash_routine"
ability,
> without being able to identify *what* the error was which forced the
crash,
> would not be entirely helpful for general-purpose use. Eventually,
somebody
> would want to know exactly *which* error had happened, in order to better
> handle the crash situation.
As far as i see, the only condition where you could get into trouble would
be when you re-enter your code at the next line, inside a loop, and hit the
same error again when looping, your handler clears it, and loops to hit it
again. But you can get into that with tests for possible errors now, can't
you? So do a "on error[1] inc x, if x > y then oops, we have an intolerable
loop, Scotty, beam me out of here!" Or, inside the error handler, do "if
this is the same error as last time, throw up your hands and refuse to deal
with it, and drop to the next error handler".
Kat,
all in favor of improvements, even if *you* don't use them.
|
Not Categorized, Please Help
|
|
