Deferred Exception Object

Another term being coined on the spot; if anyone is aware of a better name for this DesignPattern/LanguageFeature?, please ReFactor this appropriately.

A DeferredExceptionObject is a useful way of doing error-handling, with some of the advantages of ExceptionHandling and some of the advantages of other more lightweight means of handling errors (such as returning a DistinguishedObject? to indicate failure). A DeferredExceptionObject is a DistinguishedObject? with the property that any attempt to do anything with it, other than a few "safe" instructions such as testing for (in)equality, etc., causes a corresponding exception to be thrown (it may well be that the DeferredExceptionObject itself may be thrown). Suppose we have the following bit of pseudo-code, which looks up an object in an AssociativeContainer? by a key k:

 v := container.lookup(k);
Suppose, further, that there is no matching key in the container. What should lookup do? A couple of possibilities:

Or, we can use a DeferredExceptionObject. Within the container implementation; a DeferredExceptionObject is created (not raised); it can contain relevant context info - i.e.

 if (keyNotFound)
     return new DeferredKeyNotFound? (key, this);
     return value;
The client, depending on whether or not the not-found condition is expected; can do two things:

 v := container.lookup (k);
 if (v.isException()) 
     // handle not found case
 } else {
Examples of this in the wild:

The description of this pattern share large parts with some implementations of NullObject (see NullObjectImplementation). Copied from there:

''The initial motivation for this class was to get rid of these useless NullPointerExceptions, that occurred if somewhere a 'null' was returned, not handled (as it should be) and passed on and on, until sometime later the NPE was thrown and nobody knew why.

I decided to let the Null object (explicitly no singleton) know where and why it was created by storing an exception on its creation. This exception was then used on method calls, that could not produce trivial results (empty collections etc. as above) to throw a NPE, that had as the ultimate cause the stored exception. This way these common and hard to detect error cases were easily locatable.''

The application of this pattern for clean initialization (as listed above under NotInitialized? in JavaScript) is also powerful. Complex systems tend to have complex initialization mechanisms. The startup of a monolithic system as well as that of a loosely coupled container managed system can benefit from this pattern. Especially so if the setup contains (potential) cycles. Problems during initialitation like can be mediated by using this pattern. The idea is to replace not-yet initialized fields with such a DeferredExceptionObject that tells what (component, source location) is uninitialized (and maybe why). Thereby incomplete initialization shows up as a useful message instead of a NullPointerException or undefined behavior or else.

Since your intended data and the deferred exception type must be of the same type most languages, you're essentially re-inventing Haskell's Maybe type. --SamuelFalvo?

See also SentinelPattern


View edit of October 14, 2007 or FindPage with title or text search