Thread: Exceptions that should terminate. Really.

  1. #1
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446

    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?
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  2. #2
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Mario F. View Post
    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.

  3. #3
    semi-colon generator ChaosEngine's Avatar
    Join Date
    Sep 2005
    Location
    Chch, NZ
    Posts
    597
    Quote Originally Posted by brewbuck View Post
    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.
    "I saw a sign that said 'Drink Canada Dry', so I started"
    -- Brendan Behan

    Free Compiler: Visual C++ 2005 Express
    If you program in C++, you need Boost. You should also know how to use the Standard Library (STL). Want to make games? After reading this, I don't like WxWidgets anymore. Want to add some scripting to your App?

  4. #4
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by ChaosEngine View Post
    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.

  5. #5
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    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.

  6. #6
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Daved View Post
    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.

  7. #7
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    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!
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  8. #8
    The larch
    Join Date
    May 2006
    Posts
    3,573
    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.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Are Exceptions effective?
    By Petike in forum C++ Programming
    Replies: 5
    Last Post: 09-13-2008, 12:23 AM
  2. Debug --> Exceptions in Visual Studio 2005
    By George2 in forum C# Programming
    Replies: 1
    Last Post: 08-10-2007, 02:12 AM
  3. Terminate() inside constructor
    By Mario F. in forum C++ Programming
    Replies: 8
    Last Post: 07-14-2006, 03:59 AM
  4. Need advice: catch exceptions or call methods to check bits?
    By registering in forum C++ Programming
    Replies: 1
    Last Post: 10-03-2003, 01:49 PM
  5. Throwing exceptions with constructors
    By nickname_changed in forum C++ Programming
    Replies: 14
    Last Post: 07-08-2003, 09:21 AM