In C and C++ you can return a single variable inside a function. Now in the case that variable is returning data, and not an error code, you can use exceptions. But how is that possible? If you data being returned is the data you tell your function to return, then there is practically no way for the function calling it to know it's success (because the return is used for data, and not an error code). Also, the ability for a exception to literally stop the function in the middle of the code to return the error. How do C++ compilers achieve this?

  • 3
    – rwong
    Oct 5, 2013 at 11:16
  • 1
    An answer to your question might be this [thread on stackoverflow][1]. [1]: stackoverflow.com/questions/307610/…
    – theldoria
    Oct 5, 2013 at 11:17
  • 1
    All control flow structures are really just jumps ("goto") under the hood. Functions aren't obligated by the machine to return anything - in fact the machine doesn't even know what that is. The compiler handles all of that, and a thrown exception just jumps to somewhere else and doesn't use a ret to return control to the caller.
    – Aaronaught
    Oct 5, 2013 at 12:23

2 Answers 2


When a function throws an exception it does not return a value of the type specified by the function specification, and it doesn't return to the point where the function was called. It instead "returns" an exception object, and it "returns" that object to whatever catch block that catches that particular kind of exception.

That I put "returns" in quotes is intentional. It's best not to think of throw as returning a value. It instead throws a value to the catch block that handles the exception. The mechanism for handling normal function call and return is almost always implemented in the form of a call stack.

Exception handling works by a different mechanism than the call stack, but that exception handling mechanism has to do so in a manner consistent with the call stack. The catch block that catches a thrown exception might be several calls above the function that called the function that threw the exception. All of the intervening stuff, the temporary variables passed as arguments to and the local variables declared in those intervening functions, has to be cleaned up along the way. This is called "unwinding the stack".

  • Can you explain exactly how that different mechanism works and how it differs from returning from a function? Oct 7, 2013 at 15:34

There are several misconceptions underpinning your question.

First of all, the distinction you make between returning data or an error code is an artificial distinction. The C and C++ languages do not have that distinction. To them you are always returning data. It is only us programmers that attach the meaning of an error code to some of that data.

Secondly, when you leave a function, there is no requirement that you end up back at the point where the function was called. You can end up in some completely different location of the code.

Now, exceptions can be implemented in various ways. I will outline one of those ways. It is not the most efficient one, but it is one of the easiest to understand.

First I will explain how a regular function call works. When you call a function in your C or C++ code, the compiler generates instructions to take several steps. First the (values of) the arguments to the function are pushed onto the stack. Then the address is pushed where to continue processing after the function returns (with a normal return). And lastly, a jump is executed to the first instruction of the function.

For the exception handling, the compiler generates some additional information that gets placed on the stack along with the local variables. This information tells the throw statement how to clean up those local variables and where the catch blocks are located. When an exception is thrown, the throw statement walks over the stack to search for an appropriate catch block, cleaning up the local variables that it finds along the way. When an appropriate catch block has been found, a jump is performed to continue execution at that point.

As you can see, returning from a function and throwing an exception use completely different information on where to continue execution after the return/throw. For that reason, if a function does not indicate errors with an error code, but uses exceptions, you can safely presume that the function succeeded if it returns from its call. If the function had thrown, the code immediately after the function call would not have been executed.

  • -1. There are a number of things wrong with this answer. The biggest is that very few (if any!) implementations use the execution stack for exception handling. Exceptions are supposed to be exceptional -- i.e., they are presumably rare. Adding all that exception handling baggage to the stack would slow down every call, every return, and for very little gain. Most implementations use a completely distinct area than the stack for throwing and catching exceptions. Oct 7, 2013 at 15:01
  • @DavidHammen: You are right that there are no modern C++ implementations that use the scheme I outlined. The early C++ exception handling implementations (up to about MS VisualC++6) did use a scheme like this or something similar. And, you are right that the method I described has a cost also in the non-exceptional case, which is why compiler writers stopped using it. None of that makes my answer incorrect. Oct 7, 2013 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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