[LispM-Hackers] How to code for ucode "errors," unimplemented
James A. Crippen
Fri, 6 Apr 2001 12:03:22 -0800 (AKDT)
I just thought of a few standard error routines that we should provide.
Provides a mechanism for writing to standard output (or whatever the
error reporting channel is) which will warn users and developers that
the feature or mechanism being used is borken and experimental, or that
a known bug has been encountered. Searching for this string will get
you FIXME comments in your code for free, too. This function could be
turned off with some form of compile time or run time switch.
An error caused by doing something that isn't implemented yet.
An error mechanism which reports the error encountered, some supplied
string to print to the error channel, and then exits nicely, cleaning up
as necessary, and maybe writing out a core dump, status file, or the
An error which is internal to the e3 implementation (ie, is not related
to the actual functioning of the lispm, but is instead the fault of
something in the emulator).
An error which comes down from the macrocode and should cause some
microcode error condition which must be caught and handled, or cause an
An error that is a warning to the user, presumably indicating
I haven't thought about how to implement them, but I suppose something
like an e3Error class should be defined.
If e3Error is implemented then we'd have things like e3Error::Fixme(),
e3Error::Fatal() and e3Error::NotImplemented().
This would be much more effective than having an ad hoc kluge of random
errors calling exit and printing things in unreliable ways.
BTW, printing errors out should follow a standard form so they're easy to
recognize (and search for) in the output.
Here's a format that I typically use:
"*** FIXME: Don't touch that big red button. It doesn't work yet."
"*** ACHTUNG: You have done something stupid. You have been warned."
"*** ERROR: The system has fucked up and is unstable.
Writing a backtrace log... done.
Okay, thinking about it more here are some functions in the e3Error class
that want implementing. They're listed in order of severity, I think.
o NotYet() // Something isn't implemented yet.
o Fixme() // Something is borken or needs work.
o Achtung() // Which is German for "warning".
o Emulated() // An emulated error in the macrocode.
o Internal() // Something went wrong internal to the emulator.
o Fatal() // Unrecoverable error which may write a backtrace or other
// diagnostic information.
Any of the above errors (except perhaps Achtung) may additionally call
Fatal() and write diagnostic information to a file or to the error
channel. I think these are the primary public interfaces to the e3Error
If I get some spare time RSN I'll start work on fleshing out the class.
James A. Crippen <email@example.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.