🚀 go-pugleaf

gregor@netcom.com (Greg Colvin) writes:

>>Another developer on our team has asked
>>  How can we be sure that ANSI C++ library callbacks work
>>  correctly in the face of exceptions?  What if ANSI C++
>>  library code catches *our* exception?
>>

>Not to worry.

>>Is this a problem, or are library functions required to reraise any
>>exceptions thrown by client code? 
>>

>Client exceptions are intended to be pass through library code uncaught, or
>at least reraised.

I don't find that requirement in the draft. Perhaps I missed it.

In general, it seems to me that if a callback function throws an
exception that must be diagnosed as due to that callback and not to
anything else, that exception should not be derived from other
exceptions. Otherwise ALL exception-handling code must be rather
elaborate just in case some such callback might be involved (e.g.,
in a library you use but didn't write).

Every exception handler would have to determine whether the actual
exception was in fact derived from the exception it thought it
was handling, and rethrow it instead of handling it. (The current
function might not call a callback function, but one of the functions
it does call might have done so.) If you have to write all your code
like that, why use exception hierarchies at all?

I suspect it is typically the case that the callback can in fact throw
a derived exception without causing any difficulities. The callback
is in a sense part of the implementation of the called function,
and the problem it finds typically can be thought of as coming from
the called function.

For example, consider a "get_data" function that has takes a callback
to retrieve bytes from somewhere. If the callback encounters an error,
it is probably sufficient to throw an exception the get_data function
might have thrown on its own. The caller of get_data likely doesn't
care which sub-function found the problem, but only whether the
call succeeded or what class of error was found.

--
Steve Clamage, stephen.clamage@eng.sun.com


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]