TITLE: error handling schemes

(Newsgroups: comp.lang.c++.moderated, 23 Sep 97)

CUTHBERT: dacut@henry.ece.cmu.edu (David A. Cuthbert)

|>  Personally, I never use exceptions (too many paths of execution to
|>  worry about, as seen in the latest Guru of the Week).  However, I
|>  realize that people using my code might prefer to deal with them than
|>  checking for (or ignoring) error codes -- or maybe even deal with a
|>  mixture (e.g., error code on end-of-file, exception on device not
|>  present, or vice-versa).
|>  
|>  I can think of a few possible solutions:
|>  
|>  1.  An error handler for each class -- but this is hard to make
|>      changes specific to a certain instance, and also requires the
|>      handler to do any chaining.
|>  2.  An error handler for each class instance -- still requires the
|>      handler to do any chaining.
|>  3.  An error handler chain (e.g., vector <bool (MyClass::*)(error&)>)
|>      for each class -- hard to make changes specific to a certain
|>      instance.
|>  4.  An error handler chain for each class instance -- but this can
|>      require a lot of memory.

KANZE: kanze@gabi-soft.fr (J. Kanze)

My preference is for 2, but in the form of a call-back.  The default
call-back aborts with an error message, but the user can replace it with
one which throws an exception, or returns.  (The function calling the
error handler will return whatever the error handler returns.)

More generally, I use a two level approach -- the default call-back for
a class is a static variable which can be set by the user as well, so he
can either change the global behavior of the class, or change the
behavior on an instance by instance basis.  Also, of course, the error
handler is passes all necessary information about the error, so it might
return in some cases, throw an exception in others, and abort in still
others.

Finally, my error information class uses multiple inheritance in order
to derive from a standard exception, or an exception derived from the
standard class "exception", and still provide an extended interface,
including "raise" (which just does a "throw *this") and "raiseStandard"
(which throws the standard base class).

[ Of course as good OO designers the "callback" is in the form of an
  "interface" that can be mixed into a class. Right? -adc ]