[LispM-Hackers] How to code for ucode "errors," unimplemented functionality, etc

[John Morrison]

Hi Guys;

It occurs to me that, while I have the hood open on any given
macroinstruction, and the first CALL one in particular, that:

(1) There are things that are "error" conditions (e.g., calling a
DTP-FIXNUM as a function).  Parenthetically speaking (get it?), I am
curious to know how the "throwing" of ucode exceptions/errors works,
never having had the pleasure of either producing or implementing them
in the past -- but that's not the point of this message.

(2) There are things that I'm not going to get to (e.g., certainly
testing of not-yet-encountered functional object types).  In general, I
am averse to writing code for implementing branches of microcode here
that I have no way of testing yet like calling closures.  I think that
it is probably better for me to write only code that the band is asking
for up until the point we get a usable minimalist band, and then we can
generate the test cases in the emulated e3, and then implement them...

(3) There are things that Should Never Happen (i.e., WTF -- how did I
get here?).

This is particularly critical given the nature of the development
process here (a few, distributed people who almost never get more than
an hour or so at any one sitting to code).  It seems that we should
adopt a convention that helps us quickly figure out where progress has
been made (or not).

How about we adopt a convention like:

(1) Macros for ucode errors (e.g., "e3UCodeThrow(args...)"), which
probably prints some diagnostic crap contained in its args to either
stderr or whatever console or cold load stream type thing james whips
up, and then throws the error back to the macrocode via some TBD
mechanism).

(2) Not writing any "speculative" code which cannot be tested.  Use
macros for "I didn't get to this yet and have no way to test it" (e.g.,
"e3NotDoneYet(args...)") which prints sufficient clues and maybe
optionally dumps core.  This might enable us to do post-mortems via the
core dump and also grep around to find them all (i.e., we're not done
until the last of these is gone).

(3) "Real" fatal errors.  I have also defined a cpp symbol "PARANOID" in
which I try to wrap my sanity-checking and defensive code.  The intent
is that this could be undefed later to produce less assertion-checking
code.  This is pretty Old School (pre "assert"), so I am more than open
to suggestions as to how to do this better.

Let me know what you guys think...

-jm

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@mak.com