> Regarding John May's comments on Marc Snir's option "C":
> >Con: since no type checking is possible even at runtime, and since
> >all error handlers look alike, there is a danger that the user
> >will, for example, associate the same error handler with all
> >three kinds of object. This won't be detected until an actual ...
>
> I agree with this assessment. While we are dealing with admittedly
> rare circumstances - a user who *does* write an error handler - it
> seems at least a little undesireable to introduce an additional
> runtime failure mode into a situation which only exists when you
> already have an error.
I'm not so sure. When you write an error handler, you're going to write
it for a specific type, right? For example, if I write a communicator
error handler, I will only use it on comms. Who's going to try to use a
communicator error handler on a window?
Using (void *) is a very minor loss of type matching.
> >Pro: perhaps the user *wants* to write one error handler for all
> >three handles. If the handler ignores the handle passed in, it can
> >serve all three types of handle.
There is an actual use for this -- having a centralized error handler that
can dispatch the error to an appropriate routine. This can be useful in a
library environment (e.g. OOMPI) that can catch *all* errors, do some
processing (perhaps profiling types of things) and then pass the error on
to the user.
{+} Jeff Squyres
{+} squyres@cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"