Exceptions that should terminate. Really.

Well, 3rd question. I'm rolling today.

... and bumping against things all the way.

This time, still exceptions. I really feel they haven't quite registered on my brain yet. I hope the "click" will happen some day soon.

I have a few (very few) exceptions that should terminate the program. I throw an exception, for instance, when the database is corrupt or not there. I do it because std::terminate() doesn't guarantee all objects destructors down the stack will be called. So, I compromise and comment that exception class by informing users if they really want to catch, they should rethrow after doing whatever they had to do. But a comment is not part of the code. This is no good.

Is there a better way to do it? How do I force program termination with proper release of ALL resources without having to go back to error codes?

Quote:

---

Originally Posted by Mario F.

I have a few (very few) exceptions that should terminate the program. I throw an exception, for instance, when the database is corrupt or not there. I do it because std::terminate() doesn't guarantee all objects destructors down the stack will be called. So, I compromise and comment that exception class by informing users if they really want to catch, they should rethrow after doing whatever they had to do. But a comment is not part of the code. This is no good.

---

You could rethrow the exception in its own destructor. That way the user has absolutely no way of stopping it from propagating.

Quote:

---

Originally Posted by brewbuck

You could rethrow the exception in its own destructor. That way the user has absolutely no way of stopping it from propagating.

---

if you're going to do that, you may as well call std::terminate() since that's what's going to happen anyway.

Having a program abruptly die because of an exception is not good design, IMHO. If this exception is really that apocalyptic, at the very least the exception should be caught and logged in main() and a non-zero error code returned.

Quote:

---

Originally Posted by ChaosEngine

Having a program abruptly die because of an exception is not good design, IMHO. If this exception is really that apocalyptic, at the very least the exception should be caught and logged in main() and a non-zero error code returned.

---

Yeah, but I think he's talking in the context of a library, not a user program. He wants to create some sort of "invincible exception" that the user code cannot prevent from terminating the program. I have doubts about the whole concept, but threw an idea out there anyway.

I can't think of a reason why I'd want a library to terminate my program or tell me that I wasn't allowed to catch the exception without re-throwing. In the example of a corrupt or non-existant database I certainly wouldn't want that to happen.

Just throw the exception and document it well. There should be a different type (or base class or something) for exceptions that are fatal.

Quote:

---

Originally Posted by Daved

I can't think of a reason why I'd want a library to terminate my program or tell me that I wasn't allowed to catch the exception without re-throwing. In the example of a corrupt or non-existant database I certainly wouldn't want that to happen.

---

There are quite a few C libraries out there that are littered with calls to exit() when certain error conditions are met. So people have come up with all kinds of weird hacks like overriding dynamic lookup to punt the call over to a longjmp() to some higher level and other disgusting things. I've always considered such libraries to be terminally broken. So on second thought, I agree -- I think the whole idea of an unstoppable exception is unwise.

It is unwise. But I don't want an unstoppable exception either :)
Just some better scheme than a comment on the exception class code reminding users that this exceptions should almost always be fatal.

And the tip was precious:

Quote:

---

Originally Posted by Daved

Just throw the exception and document it well. There should be a different type (or base class or something) for exceptions that are fatal.

---

Thanks!

Exceptions are thrown because at that level you don't know what to do about the problem.

It's really up to the user to decide if the exception is fatal or not, when they catch it at the level where they have more information.

For example: you'd think that a missing database is going to stop me. Hell, not. I'll generate some default data to continue. Etc.

And if I can't think of a way out, I'll still want to do something. At least tell the user to stop messing with the program's files before closing.