Addition of a catch-all handler?

[elfring]

Would you like to add the construct "catch(...)" in the function "main"?

[pippijn]

There is no code path that can throw anything not derived from std::exception. Also, the article you link to says "Why Catch-All Clauses are Bad News", so I'm not sure what you're trying to tell me here.

[elfring]

I was unsure if you want to care also for other exceptions that will not be derived from "std::exception".

[pippijn]

Right, the catch-all construct would ensure proper clean-up in impossible (or unforeseen) situations. Since the only job of catch-all in main() would be to terminate the process after printing a message, there is no argument against using it. However, like I said, there is no possibility of anything not derived from std::exception being thrown, so there is no argument for using it, either. I would rather not add it, because unreachable code is generally misleading: people will ask "why is it there?" and wonder in what situations it could be reached.

[elfring]

I dared to ask for this source code addition because of a description like the following.

... Whether an uncaught exception causes the destruction of local objects during stack unwinding is implementation-dependent. ...

[pippijn]

Yes, that is true, but I think it's not that important, because there are no resources other than memory resources and file descriptors that need to be destroyed, both of which will be cleaned up by the operating system when the process terminates.

[elfring]

I assume that this detail might become a bit more interesting if objects will be introduced into your program which manage other resources.

[pippijn]

That's right, it would be interesting in that case. E.g. lock-files might be one of those resources.