OpenEuphoria

Re: crash_message

• Posted by Roderick Jackson <rjackson at CSIWEB.COM> Sep 01, 1999
• 512 views

Pete Eberlein wrote:
>I too would like to have error-handling similar to this.  I can think of
>two applications in my code:
>
>1. To restore the previous graphics mode, in case a Neil program or other
>non-Euphoria-style-graphics program crashes with an error.  Often a
>program will crash and the user will be left in a non-standard graphics
>mode where text is displayed incorrectly or not at all.  A crash routine
>would allow the program to restore the display to text mode.

Hmmm... to be honest Rob, *this* is something sorely needed.
Euphoria has a lot going for it; a nice (but not all-inclusive)
set of sequence-manipulation routines, and an adequate set of
graphics routines (at least for DOS). But it's error-handling
routines leave a bit to be desired.

In this particular case, restoring a graphics mode, I think
it's important enough that it shouldn't even fall into the
middle of a decision of whether or not to have a generic
error-handling routine specification. How about a simple set
of routines that tell the interpreter how to leave things
when it exits? You specify the details before the program
gets into the main routine (or after, at your own risk), and
at crash-time it relies on those internally-stored parameters.
A crash_graphics_mode() routine would be one of the most
important, and most elementary.

I think the concept is rather elegant; it seems to make a lot
of sense, considering that the interpreter (theoretically) is
always in control, and so should be able to do a few things
for you upon exiting/crashing. That seems to make a good
conceptual base for Euphorian error-handling.

It *might* even be possible to satisfy David's needs, while
avoiding the quagmire of a generic crash routine, by
including a crash_save() routine with the set:

   crash_save (s1, s2)

   s1 - a data object to write (as if using "print") to file
      should the program crash. Specifically, this would be
      the name of a variable storing the data. Or, it could
      be a sequence containing one or more variable names,
      which get written out in turn to the same file. Invalid
      variable names would be ignored, with an additional
      line displayed just before the real error message,
      stating that the variable couldn't be saved.

   s2 - the name of the file to write the data object(s) to.
      If the medium is write-protected or some other error
      occurs, the file simply isn't written, and an additional
      line could be added before the error message saying so.

Of course, crash_save() would probably require a lot of behind-
the-scenes changes. But even if that winds up not being a good
idea, I still earnestly ask for a crash_graphics_mode()
procedure...


Rod