I am intrigued by how the C++ exception handling mechanism works. Specifically, where is the exception object stored and how does it propagate through several scopes until it is caught? Is it stored in some global area?
Since this could be compiler specific could somebody explain this in the context of the g++ compiler suite?
Implementations may differ, but there are some basic ideas that follow from requirements.
The exception object itself is an object created in one function, destroyed in a caller thereof. Hence, it's typically not feasible to create the object on the stack. On the other hand, many exception objects are not very big. Ergo, one can create e.g a 32 byte buffer and overflow to heap if a bigger exception object is actually needed.
As for the actual transfer of control, two strategies exist. One is to record enough information in the stack itself to unwind the stack. This is basically a list of destructors to run and exception handlers that might catch the exception. When an exception happens, run back the stack executing those destructors until you find a matching catch.
The second strategy moves this information into tables outside the stack. Now, when an exception occurs, the call stack is used to find out which scopes are entered but not exited. Those are then looked up in the static tables to determine where the thrown exception will be handled, and which destructors run in between. This means there is less exception overhead on the stack; return addresses are needed anyway. The tables are extra data, but the compiler can put them in a demand-loaded segment of the program.
free() or an fclose() in some rarely used code path. –
Subassembly This is defined in 15.1 Throwing an exception of the standard.
The throw creates a temporary object.
How the memory for this temporary object is allocated is unspecified.
After creation of the temporary object control is passed to the closest handler in the call stack. unwinding the stack between throw and catch point. As the stack is unwind any stack variables are destroyed in reverse order of creation.
Unless the exception is re-thrown the temporary is destroyed at the end of the handler where it was caught.
Note: If you catch by reference the reference will refer to the temporary, If you catch by value the temporary object is copied into the value (and thus requires a copy constructor).
Advice from S.Meyers (Catch by const reference).
try
{
// do stuff
}
catch(MyException const& x)
{
}
catch(std::exception const& x)
{
}
const&, but he does not. Neither in Effective C++, nor in C++ Coding Standards (Item 73: "Throw by value, catch by reference"). Also, const whenever possible is too extreme and not what "Myers"/Meyers advised. If you intend to tweak a value, const puts unecessary burdens on the compiler. And the way to tweak exceptions (e.g. to add contextual information upon exception-propagation) is non-const/polymorhpic reference ... –
Heat const whenever possible puts burden, on both the compiler AND the programmer. Don't forget that C++ is an imperative language with state and explicit flow-control. In some situations, mutating an existing variable is simply the right thing to do; let's just start with the common for-loop and the iterator. It is possible to make loops purely const, right, by doing them via recursion, but well; same with number crunching and huge arrays; expression templates to a lot, but if flow-control reaches a critical mass, it becomes an optimization burden to the compiler ... –
Heat const by default and where reasonable, and I am aware that reasonable is relative. //// Exceptions) Well, I guess than this is personal taste. You have reasons, I (and Meyers, Alexandrescu and Sutter) have reasons, too. I just find it hard to justify to construct a completely new execption if it basically a slightly modified copy of what was caught. Imho, that's premature pessimization, as is const whenever possible. –
Heat Why do C++ programmers trust a mechanism for exceptions that the standard does not enforce implementation of? The C++ standard defines behaviors not implementation techniques. It is up-to the implementation to make sure it conforms to the standard. –
Templas How can you be sure your exceptions behave in trustworthy ways if you cannot inspect the exceptions? You can. You catch the exception. –
Templas Clearly the exceptions must be a runtime construct, and as such the exception objects must be inspectable at runtime, but is there any standard or API for inspecting the exceptions? You catch the exception. Then you can examine it. –
Templas why don't we just use functions with error callbacks and default to(if no callback is given) not blowing up our program each time an exception is thrown? Your are basically asking why C code is so brittle. Exceptions were designed to stop people forgetting to handle exception and thus blowing up the code in undiagnosable ways. Now it blows up showing you what went wrong and forcing you to handle the error condition (or if you don't handle it terminating the application in a controlled manner so your data is not corrupted). –
Templas You could take a look here for a detailed explanation.
It may also help to take a look at a trick used in plain C to implement some basic sort of exception handling. This entails using setjmp() and longjmp() in the following manner: the former saves the stack in order to mark the exception handler (like "catch"), while the latter is used to "throw" a value. The "thrown" value is seen as if it has been returned from a called function. The "try block" ends when setjmp() is called again or when the function returns.
I know this is an old question, but there's a very good exposition, explaining both the methods used in each of gcc and VC here: http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012-Skochinsky-Compiler-Internals.pdf
© 2022 - 2024 — McMap. All rights reserved.