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:

* Throw an exception. Many languages incur a penalty if you do this; plus a "no such key" condition is frequently an ''expected'' rather than an ''unexpected'' condition when performing a lookup. It would be a royal pain to have to wrap every call to lookup in a try block (or whatever your favorite language provides) just to handle missing keys. The good thing about this is that it makes it harder to ignore the error (you could use an EmptyCatchClause, but that's a no-no in most books).

* Return a tuple of <found,value>. The C++ StandardTemplateLibrary does this for its associative containers. This works, but it's easy to ignore the error; and the "value" field may contain nonsense if the "found" field is false.

** Can you cite an instance in the STL where this is done? I think you may be mis-remembering ''insert'', which returns ''pair<bool,iterator>''. In this case, the ''bool'' indicates whether the item already existed; the iterator is always valid. ''Find'' operations typically return an ''iterator'', which can be tested against ''end()'' to determine if a match was made.

* Return an error code/status; use an "out" parameter to contain the value.  Similar to the tuple solution above; makes it harder to use the lookup in an expression.

* Return a DistinguishedObject - one not in the domain of the container. In some languages, this might be easier said than done.

* Return a NullPointer. Works if null isn't in the domain of the container (but is a legal value to pass in); but in many cases a) null is a valid value for the container to hold, or b) may not be stored in the return type. When null ''does'' work, it can resemble the DeferredExceptionObject (as dereferencing it produces a NullPointerException in many languages - figuring out why NullPointerException was raised can be a pain though).

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);
 else
     return value;
The client, depending on whether or not the not-found condition is expected; can do two things:

* If not-found is expected; check to see if the result is a DeferredExceptionObject

 v := container.lookup (k);
 if (v.isException()) 
 {
     // handle not found case
 } else {
     v.frozzle();
 }
* If a not-found condition is ''not'' expected; just use the result. If not-found occurs, the exception is then raised.

Examples of this in the wild:

* The SignallingNan, defined by the IEEE754 floating point standard, is a DeferredExceptionObject with hardware support on most architectures.

* Likewise with the NullPointer; though null gives you no context whatsoever.

* The NotInitialized value in JavaScript (did I spell that right), which variables get initialized to if not explicitly initialized.

* DoesNotUnderstand, and other error messages in Smalltalk, have this behavior.

----

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 NullPointerException''''''s, 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
* missing dependencies to requrired resources
* long chains (cycles) of dependencies ending in an unitialized component
* useless error messages in case of components missing initialization
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

----

CategoryException