easy to miss bug (even in structured debug)

[Eric Dean Tribble <tribble>]

Abstract: Even though we have some good conventions for handling NULL,
we can't statically check for NULL errors.  I'm using NULL return
values *a lot* for the splay ent (to represent empty subtrees).
That's why I'm nervous about the bug.  After everything works I'll
explore some ideas for removing the use of NULLs.

   However, because we signal exceptions with BLASTs, the normal return
   path corresponds to success, and therefore NULLs are much rarer in our
   code.

Many routines that take slices in the ent (copy, splitReadyFromRest,
sharedWith:) can reutnr either a new crum or NULL if the branch being
examined doesn't meet with the slicing criteria.  Returning NULL is
*not* an exceptional condition in that it is as likely and meaningful
as a crum to many of the ent routines.  I have some ideas to avoid
using NULLs, but they will wait till everything works.

   3) Any function parameter that may be passed a NULL be declared with
   NULL as its default value.  This is intuitively sensible as NULL can
   then be read as indicating the lack of an argument in that position.

This is real good (but a pain in Smalltalk).  

   We should take these conventions to be part of the meaning of a class
   declaration as a contract.

No.  They are too ad hoc.  They also don't support the style I'm
currently using (that may an indictment of the current style).  The
use of macros like I described covers all the cases that come to mind
(get returns an Heaper, fetch returns void_AS(Heaper), for example).

   To any of you other X++ programmers who are using these conventions:
   Have you also experienced a pleasing absence of NULL bugs?  If the
   answer is yes, are we trying to solve a problem we don't have?

I currently have the problem.  So do you, but you've generated some
(good) ad hoc solutions for dealing with it.  I wqould be easier to
communicate a somewhat more regular solution to 3rd parties (no rush,
I realize).

We can wait on taking action till I reexamine the code to remove
NULLs.  If I can do it, then we shouldn't spend any more time on this
(except for fun :-).  eot (end of thread).

dean