1. Re: crash_message
Interesting. Nobody seems to want to respond to the points I raised earlier.
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? 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?
Gabriel Boehme
-----Original Message-----
From: Boehme, Gabriel [mailto:gboehme at postoffice.musicland.com]
Sent: Thursday, September 02, 1999 2:21 PM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: crash_message
Pete Eberlein wrote:
>>Basically, a unrestricted, generic error routine has powerful
>>potential uses, but it also has all the elegance & structural
>>integrity of a "goto" (I can already envision a flame or two
>>from this one...)
>
>No flames here, it is an evil goto, plain and simple. You could
>even use it to make your program "crash-proof" (at the expense
>of an infinite loop.)
>
>-----------------------------------------
>procedure main()
> ? somevar / 0 -- do something stupid
>end procedure
>
>procedure crash_handler()
> -- FYI message
> puts(1, "got a error (heh heh)\n")
>
> -- re-register the crash handler (assuming
> -- it is removed before it is called)
> crash_routine(routine_id("crash_handler"))
>
> -- continue processing
> main()
>end procedure
>
>-- register the crash handler for the first time
>crash_routine(routine_id("crash_handler"))
>
>main()
>-----------------------------------------------
This example made me think of another important question -- how would this
crash routine know *which* error had occurred? It would have to be something
like this:
include crash.e
procedure crash_handler(integer crash_code)
if crash_code = DIVIDE_BY_ZERO then
-- where?
elsif crash_code = TYPE_CHECK_ERROR then
-- which type, and where?
elsif crash_code = SEQ_LENGTH_MISMATCH then
-- where, and what values?
else
-- how many more kinds of errors?
end if
end procedure
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.
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.
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.
So, if we want to add this ability to the language, we'd better come up with
a good way of dealing with error codes.
Gabriel Boehme
