Re: use exception in default catch(...)
Randy wrote:
James Kanze wrote:
josephgarry@gmail.com wrote:
In a default catch(...), I'd like to be able to look at the exception
that was caught, or somehow see what was thrown.
This would be immensely useful, for instance, in some sort of exception
handler one might have in main(), for instance.
It's also essential in multi-threaded code, in order to
propagate an unknown exception type accross a join. I believe
that the issue is being currently addressed in this context in
the committee. It's still rather vague (in my mind, at least),
but the committee is aware of the problem, and giving it some
consideration. (That doesn't mean that there will be an
absolute solution. The committee could well decide that only
certain types of exceptions can be propagated. But given that
the compiler has this information somewhere, consideration is
being given to making it available to the user.)
But, why would you want to propagate an exception out of the thread in
which it occured?
Who knows? It depends on the application. I'd say that most of
the time, it doesn't make sense. But that "most of the time" is
based on my personal experience, and there are some important
programming domains where I've no experience.
And what would that even mean?
Since each thread has its own stack, and exception propagation unwinds
the stack, does that not mean that propagating the exception beyond the
thread in which it occurred would be unwinding beyond the top of that
thread's stack? Is that desirable, or even possible?
You're thinking too much at an implementation level. Exceptions
are a mechanism for reporting errors. Surely you wouldn't
claim that there is never a reason for an error report to
transit thread boundaries.
Seems to me that if an exception in a thread reaches the top of that
thread's stack that should be the same as an unhandled exception trying
to percolate out of main(), and should be handled exactly the same way.
At the language level, I agree. The problem is that as it
currently stands, the user has no means of capturing the error,
encapsulating it, and reporting it back to the joining thread.
What we'd like is that the user could somehow write low-level
thread handling code (which knows nothing of the types of
exceptions it might encounter) which does something like:
in the thread:
try {
// call the high level stuff...
} catch ( ... ) {
// package the exception and return it
// back through the join...
}
// package the normal return value and return it back
// through the join
and in the joining thread:
myThread.join() ;
// Test whether there was a returned exception.
// If so, unpackage it and throw it...
// Get the packaged return value, unpackage it,
// and return it.
I don't have any such use cases in my application domains, but
others apparently do, and the request to be able to do this
sounds reasonable to me.
The problem is, how do you repackage something without knowing
either its type or its value. Within the catch block, the
compiler does have this information, somewhere, and it doesn't
seem unreasonable to me to add global functions to the library
which would return the type, or return a void* to the cloned
value, or maybe which would return an extended object which
contained a pointer to the cloned value, and had a function to
throw the cloned value as an exception. Or something along
those lines.
Not that I think it essential. I could also accept the idea
that only specific types of exceptions could be propagated, say
those which derive from std::exception. If that were the case,
it would be sufficient for std::exception to support virtual
functions to clone the object and to raise an exception of the
most derived type. In which case, the above code becomes:
returnValueSlot = NULL ;
exceptionSlot = NULL ;
try {
// call the high level stuff...
returnValueSlot = returnValue ;
} catch ( std::exception const& error ) {
exceptionSlot = error.clone() ;
}
....
myThread.join() ;
if ( exceptionSlot != NULL ) {
exceptionSlot->raise() ;
}
return *returnValueSlot ;
(There are object lifetime issues here, which are difficult to
solve without garbage collection.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]