How does compiler handle exceptions that are implicit? Looking for design strategies

Question

Throughout the function handleException, the exception encountered is implicit. How does the compiler handle such implicit passing of exceptions? [For e.g. in C++ methods, this pointer is passed to account for the current object. My question is how does a compiler handle exceptions internally - handleException has no arguments.]

 void handleException()
 {
 try {
 throw;
 }
 catch (MyException& e) {
 ...code to handle MyException...
 }
 catch (YourException& e) {
 ...code to handle YourException...
 }
 }
 void f()
 {
 try {
 ...something that might throw...
 }
 catch (...) {
 handleException();
 }
 }

• Loki Astari: That's now how it is used in C++. You need to ask on SO how the throw clause works. I have not come across a language that has the concept of implicit exceptions (I suppose they could exist). The better question is why would you want such a concept, it seems very error prone in its usage.
• Fred Nurk: @Martin: That is one way it is used in C++, see C++03 §15.1p6.
• Loki Astari: @Fred Nurk: From n3225. 15.1p8<quote>A throw-expression with no operand rethrows the currently handled exception.</quote>15.1p9<quote>If no exception is presently being handled, executing a throw-expression with no operand calls std::terminate()</quote>. So No. There is NEVER an implicit exception that is thrown.
• Fred Nurk: @Martin: Where is the exception mentioned in the throw; statement? If it is not mentioned, is that not implicit? It sounds like you are forming an opinion based on the title alone without actually reading the question body, which explicitly mentions what the OP means by "implicit" (which is also not a term used in the standard).
• Alf P. Steinbach: @Martin York: it's a construct that ideally would be used to translate exceptions when you're using two or more libraries with non-standard exceptions. It never got into general use, I think mostly because earlier (when such libraries abounded) Visual C++ compilers had a bug that caused exception object's destructor to be called twice for this construct. And nowadays libraries just use standard exceptions, so generally no need. Cheers & hth.,

Answer 1

Pay no attention to that man behind the curtain.

Because the compiler knows how it implements exceptions, it can use that internal information. The simplest way is to use a global (or thread local) variable to store info about any "active" exception; then retrieve that, mostly to get type info, and propagate. C++0x partially exposes this information with std::exception_ptr; see §18.8.5 in N3225.

Exceptions are handled differently from parameters; analogy to "this" won't be helpful. The value for "this" is usually treated as a normal pointer parameter, except for being hidden from the user behind the curtain.