Try / catch the whole program
I am used to building my C ++ projects like this:
int main(int ac, char* av[])
{
try
{
Object foo;
foo.run()
/* ... */
}
catch (const std::exception& e)
{
std::cerr << e.what() << std::endl;
return 1;
}
catch (...)
{
std::cerr << "Unknown error." << std::endl;
return 1;
}
return 0;
}
I wonder if this is a good thing, or is it better to use try / catch blocks on small chunks of code that are "expected" for errors to occur?
source to share
You can put your entire program in such a top-level exception handler if you want to control how unhandled exceptions are handled (if they reach the top level).
There is a drawback to this: the default crash behavior is preemptive, which probably means you don't have crash dumps, and thus missing important post-mortem debugging information.
In addition, they may not reach the top level, but result in std::unexpected()
and are thus called std::terminate()
.
This way, you may be better off std::set_terminate
even if you want to do your thing.
Consider doing your own thing and then crashing as usual (which you cannot do with your global exception handler).
source to share
Generally, catching all exceptions is not a good idea: you only want to catch those exceptions that your particular piece of code is willing to handle in a meaningful way.
However, the top-level entry point is an exception to this rule: it is common practice to catch all exceptions yourself if you want to control how top-level exceptions are handled.
The usual way to implement it is to write one function that looks like main
but has a different name:
int entryPoint(int argc, char *argv[]) {
... // The real logic goes here
Object foo;
foo.run()
/* ... */
}
Your code looks like this and never changes:
int main(int ac, char* av[])
{
try
{
return entryPoint(ac, av);
}
catch (const std::exception& e)
{
std::cout << e.what() << std::cerr;
}
catch (...)
{
std::cout << "Unknown error." << std::endl;
}
}
source to share
The benefit of your program never crashes (on Linux it can spin hard as signals cannot be caught as exceptions)
But there is one drawback I can think of: when you debug your code and have a runtime error, you don't know where it is or you see the stack. since your program continues to run from the catch. so instead of immediately checking what happened, you need to run again and hope you have the same behavior.
Another thing: if your program is multithreaded, this will not help catch all the exceptions, since each thread must catch its own exceptions.
source to share
Of course, it's best to try / catch as close to the throw as possible if there is something you can do to recover from the mistake. Catching every fatal error, on the other hand, can clutter your code a bit.
If the throw is not caught, it will be called std::terminate
and you can set this function to a custom one std::set_terminate
. Inside the completion function, you can do throw;
that jumps over the uncaught object and then catch it. You should use catch(...)
at the end in this case, as throwing from the completion function is not very good.
source to share
Yes, of course it will make a difference ... Let's see how.
try
{
// code which could throw an exception
}
catch(Myexception& e) //derived from std::exception
{
//do something.
}
//..some more code. //Point_1
Let's say I just want to do some manipulation after catching Myexception and then resuming this function. After you catch the exception code, you will be taken to POINT_1. If I were to encapsulate this in a try / catch, it would be ignored.
source to share