WTF in class project spec



  • I found this in the spec of my databases class project.  The code has every sign of being poorly converted from C to C++, but this takes the cake.  And yes, it's very common in this project for constructors to return a status code through a reference parameter.  I guess they don't believe in exceptions.

    Index * index = new Index(relation, status);
    if(!index) return INSUFMEM;
    if(status != OK) return status;



  • @Jonnyothan said:

    I found this in the spec of my databases class project.  The code has every sign of being poorly converted from C to C++, but this takes the cake.  And yes, it's very common in this project for constructors to return a status code through a reference parameter.  I guess they don't believe in exceptions.

    Index * index = new Index(relation, status);
    if(!index) return INSUFMEM;
    if(status != OK) return status;


    Not a WTF. Like the name says, exceptions should be used for exceptional events only. On todays machines with only 2 Gigs of physical RAM and a not much more virtual memory space, running out of memory while allocating a few bytes is a prevalent problem.

    ;-)



  • 'Only' 2 gigs?

    What?

    You're talking about servers, right?



  • Wait.

    ;-)


    I'll take my sarcasm meter back to the shop, one of these days.



  • <FONT color=#000000 size=2>I guess they don't believe in exceptions.</FONT>

    <FONT size=2>
    </FONT>And here I thought there was a rule that said constructors couldn't throw exceptions.  I guess I need to look that up again.



  • Well, you might run out of memory if Index returns a bad status often enough ;)



  • There can be several reasons not to use exceptions.

    One good reason is portability. I've worked in a project where code that was as good as platform independent had to be ported to HPUX and had to be linked to an existing product. That had been compiled using HP's compiler. But our code used templates and exceptions and singletons and whatever, and HP's compiler didn't like that. And although g++ was available, it was impossible to link its output to that of the HP compiler.

    Exceptions can also be a pain in the backside in plug-ins. In one case, I remember that an uncaught exception in a plug-in would simply halt the whole application, and most people don't like it when that happens to their favorite office suite. In another, the plug-in had to be linked to an older library which clashed with exception handling. In general, exceptions should not be thrown across the API.

    And then I remember a bug in the Windows standard library interface which did something weird copying string in an exception in a constructor that opened a file under low memory conditions. If they hadn't done that, one of my colleagues could have spent two weeks on holidays and still finished the project at the same time...

    No, exceptions may look elegant, but remember that they're usually tacked on to an older architecture...



  • @mrprogguy said:

    And here I thought there was a rule that
    said constructors couldn't throw exceptions.  I guess I need to
    look that up again.



    I can't remember about constructors, but you definatly, definatly, definatly, should not throw an exception from a DEstructor.



  • class cancelDetonation(int delay) throws KaBoomException {}

    ?



  • @firewireguy said:

    I can't remember about constructors, but you definatly, definatly, definatly, should not throw an exception from a DEstructor.


    I think it's legal and possible though. E.g., allocating memory in the destructor, writing to disk, etc., can evoke an exception. It can however result in an inconsistent memory state, so you have to be careful.

    There's nothing magical about constructors and destructors. They're just functions that get called (in a particular order) after/before memory allocation/deallocation. You only have to make sure you wave your wand in the right direction and sacrifice the appropriate animal to have your class protected against the std::exception spell. Also invoke the right spirit: don't call on Stroustrup if you're using STL without any inheritance. I have known a programmer who did so, and well, they say he can go back to work now any day soon...



  • @TGV said:



    I think it's legal and possible though. E.g., allocating memory in the destructor, writing to disk, etc., can evoke an exception. It can however result in an inconsistent memory state, so you have to be careful.

    There's nothing magical about constructors and destructors. They're just functions that get called (in a particular order) after/before memory allocation/deallocation. You only have to make sure you wave your wand in the right direction and sacrifice the appropriate animal to have your class protected against the std::exception spell. Also invoke the right spirit: don't call on Stroustrup if you're using STL without any inheritance. I have known a programmer who did so, and well, they say he can go back to work now any day soon...


    I think in garbage-collecting systems like Java and .net it is senseless for a destructor to throw an exception, since it is indeterministic if, how and when it will be executed.



  • @TGV said:

    @firewireguy said:
    I can't remember about constructors, but you definatly, definatly, definatly, should not throw an exception from a DEstructor.


    I think it's legal and possible though. E.g., allocating memory in the destructor, writing to disk, etc., can evoke an exception. It can however result in an inconsistent memory state, so you have to be careful.

    There's nothing magical about constructors and destructors. They're just functions that get called (in a particular order) after/before memory allocation/deallocation. You only have to make sure you wave your wand in the right direction and sacrifice the appropriate animal to have your class protected against the std::exception spell. Also invoke the right spirit: don't call on Stroustrup if you're using STL without any inheritance. I have known a programmer who did so, and well, they say he can go back to work now any day soon...
    If you throw an exception all the classes on the stack get unwound to the catch block, and all their destructors are called in doing so.  If any of these classes throw ANOTHER exception in their destructor the you're is fucked, does it head for the original catch or the new catch block?  There's no answer, so the C++ spec says it will call terminate() at this point.  Bang!  You're dead!


Log in to reply