Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 {
   catch (MyException& e) {
     ...code to handle MyException...
   catch (YourException& e) {
     ...code to handle YourException...

 void f()
   try {
     ...something that might throw...
   catch (...) {
share|improve this question
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. – Loki Astari Jan 19 '11 at 6:26
@Martin: That is one way it is used in C++, see C++03 §15.1p6. – Fred Nurk Jan 19 '11 at 6:32
@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. – Loki Astari Jan 19 '11 at 6:36
@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). – Fred Nurk Jan 19 '11 at 6:43
@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., – Alf P. Steinbach Jan 19 '11 at 7:03
up vote 3 down vote accepted

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.