Out of my curiosity..
I notice when I throw exceptions from constructor, if I compiled the code in debug mode and if I click on continue debugging (or continue stepping through), it won't exit the constructor until it reaches the end. Please note I don't have try{}catch{} wrapping the code that instantiate MyClass object.
I tried this in release mode, and can't really tell if it exits the constructor after the first throw or the last throw. Do you know if in release mode it leaves ctor since the first throw or the last? And why does it let me go to the next line when I'm in debug? shouldn't throw just exit the scope it's in?
MyClass::MyClass()
{
throw "exception1";
throw "exception2";
throw "exception3";
}
MyClass a;
I suspect that it's a debugging issue. An uncaught exception should, by default, kill the program. But your debugger stops the program at the line that caused the exception, instead. And the "continue debugging" button tells the debugger to just ignore the last fatal problem and continue going.
So the debugger continues on in the program until it reaches the second throw. Which would, again, be fatal. So the debugger stops there. Etc.
If there's a place that actually catches the thrown exception, you should see different behavior.
Related
I have a non-void function which returns a value to be used as an input of a class constructor, but there is a possibility for that value not to be available, so I want to return the value in case of success or just terminate (std::terminate()) the application in case of failure before the function return.
Since std::terminate is called by the runtime according to https://en.cppreference.com/w/cpp/error/terminate, am I obliged to throw an exception and let the runtime decide whether the program is terminated or not?
What about the following warning I read in a simple test I just performed? "terminate called without an active exception"
Am I going in a stupid way?
Thanks for your insights in advance!
... I obliged to throw an exception and let the runtime decide whether the program is terminated or not?
It is up to you. If you want to be able for an exception to be caught somewhere up the call stack then you should throw an exception. In cases you want to terminate because there is no way to recover then calling std::terminate is fine. Just consider that if you throw an exception which is not caught then the program terminates anyhow, so you can choose to either catch it or not, while std::terminate terminates always.
The same page that you linked to, in your question, also has the following statement:
std::terminate() may also be called directly from the program.
I set a breakpoint in a destructor, which only gets called, when the program finishes completely. Now I start the program with CLion's debugger, but it never reaches the destructor. When I press on finish in CLion the debugger closes and the breakpoint never gets reached. How can I reach the breakpoint in the destructor in CLion?
You need to find a way to stop looping in your main thread, and jump to return 0; at the end of your int main(...) {. Alternatively, you can use exit(0), I believe. (Source: Difference between "return 0" and "exit (0)")
There's more:
You need to share your code, but there's this information, which you may find useful:
Please see these references:
Are Basic Object Destructors Called On Exit()?
Note that objects with automatic storage are not destroyed by calling exit (C++).
http://www.cplusplus.com/reference/cstdlib/exit/
The problem could be that, during exit, your destructor is never called, anyway. Hence, it is a leak but the OS will handle it.
This is the code:
#include <iostream>
void f() {
throw 1;
std::cout << "f(): should not be printed!!\n";
std::cout << "f(): not should this!!\n";
}
int main(int, const char**) {
f();
std::cout << "main(): This not be printed!!\n";
return 0;
}
When run as a console application, in debug mode and under the debugger there is no stack unwinding and the cout statements get printed?
This is technically possible if you run with the debugger. You didn't tell the whole story though. The debugger will display a dialog first when the exception is thrown. It looks similar to this (mine is VS2012 on Windows 8):
If you click the Break button then the debugger will break at the throw statement, giving you a chance to inspect state. When you click the Continue button then the exception is ignored and the program will continue as though nothing happened. This also happens when you break and then resume running.
This is a feature, not a bug, it allows you to rescue a debug session on which you already spent a lot of time. It is of course not often that useful to continue since your program is likely to be in a bad state but the alternative isn't great either. You almost always want to favor clicking Break and use the debugger to correct state so that you can meaningfully continue debugging.
Of course this will never happen without a debugger, your program will instantly terminate.
The only possible way that a stack unwind is ever going to happen is by writing a catch clause that catches the exception. Regardless of whether you are debugging or not.
The key in answering my own question lies in answering another sub-question: right after an exception is thrown, at which point does the stack unwinding begin? By stack unwinding is meant the call, in reverse order, of destructors of all automatic objects that still exist. Answer: at the point the control is passed to the exception handler, i.e. the exception is caught. If the exception is not caught, the C++ exception mechanism dictates that the terminate function is to be called and this in effect by default calls abort(). This mechanism can be seen in action by the following code:
struct X {
~X() { std::cout << "~X !!\n"; }
};
int main(int, const char**) {
X x;
throw 1;
return 0;
}
After the throw, the destructor for X is never called because the no exception handler has gained control and so the program aborts.
Back to the initial question, in the situation of when you are debugging a debug build and during execution of the program an exception is thrown when there is no suitable try-catch block around it, the MS Studio debugger breaks at the throw point and presents you with the dialogue window shown above and provides you with the option to “continue”. Continue is to be interpreted not as “carry on with the exception mechanism” but as “carry as if nothing has happened” i.e. with the next line of code after the throw.
I have some technical questions. In this function:
string report() const {
if(list.begin() == list.end()){
throw "not good";
}
//do something
}
If I throw the exception what is going on with the program? Will my function terminate or will it run further? If it terminates, what value will it return?
If you throw an exception, all functions will be exited back to the point where it finds a try...catch block with a matching catch type. If your function isn't called from within a try block, the program will exit with an unhandled exception.
Check out https://isocpp.org/wiki/faq/exceptions for more info.
It will basically go up the stack until it finds an exception handler; if it gets to the end of the stack without finding one, your program will crash. If it does find one, it will rewind the stack up that point, run the handler, and continue with the code after the handler block, however far up your stack that may be.
You can get all sorts of details about C++'s exception handling mechanism through Google. Here's a head start.
Since you're not catching the exception within the context of the function, the function will terminate and the stack will be unwound as it looks for an exception handler (a catch block that would match either string, or the generic catch(...)). If it doesn't find one, your program will terminate.
Your function will terminate immediately, and it won't return anything. If there are no catch statements catching the exception "up the call chain", your application will terminate.
It won't return, it will in fact terminate and reach the "nearest" (call-stack-wise) try...catch block.
If none is found, most of the time the program just exits, on some platforms the error can be printed, I don't know the specifics of that though (and most likely only the ones derived from std::exception).
What's the difference between those three, and how shall I end program in case of exception which I can't handle properly?
abort indicates "abnormal" end to the program, and raises the the POSIX signal SIGABRT, which means that any handler that you have registered for that signal will be invoked, although the program will still terminate afterwords in either case. Usually you would use abort in a C program to exit from an unexpected error case where the error is likely to be a bug in the program, rather than something like bad input or a network failure. For example, you might abort if a data structure was found to have a NULL pointer in it when that should logically never happen.
exit indicates a "normal" end to the program, although this may still indicate a failure (but not a bug). In other words, you might exit with an error code if the user gave input that could not be parsed, or a file could not be read. An exit code of 0 indicates success. exit also optionally calls handlers before it ends the program. These are registered with the atexit and on_exit functions.
std::terminate is what is automatically called in a C++ program when there is an unhandled exception. This is essentially the C++ equivalent to abort, assuming that you are reporting all your exceptional errors by means of throwing exceptions. This calls a handler that is set by the std::set_terminate function, which by default simply calls abort.
In C++, you usually want to avoid calling abort or exit on error, since you're better off throwing an exception and letting code further up the call stack decide whether or not ending the program is appropriate. Whether or not you use exit for success is a matter of circumstance - whether or not it makes sense to end the program somewhere other than the return statement in main.
std::terminate should be considered a last-ditch error reporting tool, even in C++. The problem with std::terminate is that the terminate handler does not have access to the exception that went unhandled, so there's no way to tell what it was. You're usually much better off wrapping the entirety of main in a try { } catch (std::exception& ex) { } block. At least then you can report more information about exceptions that derived from std::exception (although of course exceptions that do not derive from std::exception would still end up unhandled).
Wrapping the body of main in try { } catch(...) { } isn't much better than setting a terminate handler, because again you have no access to the exception in question. There is at least one benefit, though: whether stack unwinding is done when an exception goes completely uncaught is implementation defined, so if you need guaranteed stack unwinding, this would be a way to get that.
std::abort and std::exit (and more: std::_Exit, std::quick_exit) are just lower level functions. You use them to tell the program what you want it to do exactly: what destructors (and if) to call, what other clean-up functions to call, what value to return, etc.
std::terminate is a higher level abstraction: it is called (by either run-time or you) to indicate that an error in the program occurred and that for some reason it is not possible to handle by throwing an exception. The necessity for that typically occurs when error occurs in the exception mechanism itself, but you can use it any time when you do not want your program to continue beyond the given error. I compiled the full list of situations when std::terminate is called in my post. It is not specified what std::terminate does, because you are in control of it. You can configure the behavior by registering any functions. The limitations you have are that the function cannot return back to the error site and it cannot exit via an exception, but technically you can even start your message pump inside. For the list of useful things that you can do inside, see my other post.
In particular, note that std::terminate is considered an exception handler in contexts where std::terminate is called due to a thrown exception that could not be handled, and you can check what the exception was and inspect it by using C++11 using std::rethrow_exception and std::current_exception. It is all in my post.
quick_exit() !
If your program is multi-threaded, then calling exit() will most likely result in a crash because global/static std::thread objects will be attempted to destruct without exiting their threads.
If you want to return an error code and exit the program (more or less) normally, call quick_exit() in multi-threaded programs.
For abnormal termination (without a possibility for you to specify the error code), abort() or std::terminate() can be called.
Note: quick_exit() has not been supported by MSVC++ until version 2015 .
terminate() is automatically called
when an exception occurs that cannot
be handled. By default, terminate()
calls abort(). You can set a custom
handle with set_terminate() function.
abort() sends the SIGABRT signal.
exit() is not necessarily a bad
thing. It successfully exits the
application, and calls atexit()
functions in LIFO order. I don't
normally see this in C++
applications, however, I do see it in
many unix based applications where it
sends an exit code at the end.
Usually a exit(0) indicates a
successful run of the application.
terminate leaves you the possibility to register what will happen when it is called. Should be one of the other two.
exit is a normal exit allowing to specify an exit status. Handlers registered by at_exit() are run
abort is an abnormal exit. The only thing which is ran is the signal handler for SIGABRT.
My advice would be not to use any of them. Instead, catch the exceptions you can't handle in main() and simply return from there. This means that you are guaranteed that stack unwinding happens correctly and all destructors are called. In other words:
int main() {
try {
// your stuff
}
catch( ... ) {
return 1; // or whatever
}
}