Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualsamoth

Posted 20 August 2013 - 07:17 AM

Note that throwing an exception from a destructor is also super bad mojo in C++. Basically any exception guarantees go out the window if you have destructors that throw. It's sufficiently bad that C++11 gave all destructors an implicit noexcept exception specification, meaning that an exception from a destructor will immediately call terminate() unless you specifically enable exceptions for the destructor for the class or one of the subobjects of that class contains a destructor which has exception enabled destructors.

 

Actually I find this one of the more valuable additions to C++11, because if your destructor throws, something is seriously fucked up. At least, usually... there may be singular cases where it may be allowable and desirable, but I must admit I don't see them. I do see the problems, though.

 

Either you have a "conditional destructor" with some (hopefully bulletproof) logic that prevents it from throwing while being unwound, then your class behaves differently although the expectation would be that it works the same. You now need a separate way of detecting the error condition, or you must simply ignore the error. Either way, this stinks.

 

Or, you are unaware of what happens when you throw from a destructor during unwind, and do it anyway. This is even worse, in two respects (first, because you don't know the implications, and second because it actually happens, and the program is now in an undefined, unrecoverable state). And, what's worst, now you don't even know what happened, or where.

 

So, for that this case, crashing hard by terminating the program is a good thing. It forces the programmer to address the issue. Actually, the mere presence of the throw keyword inside a destructor should preferrably generate a build error, if you ask me.


#4samoth

Posted 20 August 2013 - 07:17 AM

Note that throwing an exception from a destructor is also super bad mojo in C++. Basically any exception guarantees go out the window if you have destructors that throw. It's sufficiently bad that C++11 gave all destructors an implicit noexcept exception specification, meaning that an exception from a destructor will immediately call terminate() unless you specifically enable exceptions for the destructor for the class or one of the subobjects of that class contains a destructor which has exception enabled destructors.

 

Actually I find this one of the more valuable additions to C++11, because if your destructor throws, something is seriously fucked up. At least, usually... there may be singular cases where it may be allowable and desirable, but I must admit I don't see them. I do see the problems, though.

 

Either you have a "conditional destructor" with some (hopefully bulletproof) logic that prevents it from throwing while being unwound, then your class behaves differently although the expectation would be that it works the same. You now need a separate way of detecting the error condition, or you must simply ignore the error. Either way, this stinks.

 

Or, you are unaware of what happens when you throw from a destructor during unwind, and do it anyway. This is even worse, in two respects (first, because you don't know the implications, and second because it actually happens, and the program is now in an undefined, unrecoverable state). And, what's worst, now you don't even know what happened, or where.

 

So, for that this case, crashing hard by terminating the program is a good thing. It forces the programmer to address the issue. Actually, the mere presence of a throw keyword inside a destructor should preferrably generate a build error, if you ask me.


#3samoth

Posted 20 August 2013 - 07:16 AM

Note that throwing an exception from a destructor is also super bad mojo in C++. Basically any exception guarantees go out the window if you have destructors that throw. It's sufficiently bad that C++11 gave all destructors an implicit noexcept exception specification, meaning that an exception from a destructor will immediately call terminate() unless you specifically enable exceptions for the destructor for the class or one of the subobjects of that class contains a destructor which has exception enabled destructors.

 

Actually I find this one of the more valuable additions to C++11, because if your destructor throws, something is seriously fucked up. At least, usually... there may be singular cases where it may be allowable and desirable, but I must admit I don't see them. I do see the problems, though.

 

Either you have a "conditional destructor" with some (hopefully bulletproof) logic that prevents it from throwing while being unwound, then your class behaves differently although the expectation would be that it works the same. You now need a separate way of detecting the error condition, or you must simply ignore the error. Either way, this stinks.

 

Or, you are unaware of what happens when you throw from a destructor during unwind, and do it anyway. This is even worse, in two respects (first, because you don't know the implications, and second because it actually happens, and the program is now in an undefined, unrecoverable state). And, what's worst, now you don't even know what happened.

 

So, for that this case, crashing hard by terminating the program is a good thing. It forces the programmer to address the issue. Actually, the mere presence of a throw keyword inside a destructor should preferrably generate a build error, if you ask me.


#2samoth

Posted 20 August 2013 - 07:15 AM

Note that throwing an exception from a destructor is also super bad mojo in C++. Basically any exception guarantees go out the window if you have destructors that throw. It's sufficiently bad that C++11 gave all destructors an implicit noexcept exception specification, meaning that an exception from a destructor will immediately call terminate() unless you specifically enable exceptions for the destructor for the class or one of the subobjects of that class contains a destructor which has exception enabled destructors.

 

Actually I find this one of the more valuable additions to C++11, because if your destructor throws, something is seriously fucked up. At least, usually... there may be singular cases where it may be allowable and desirable, but I must admit I don't see them. I do see the problems, though.

 

Either you have a "conditional destructor" with some (hopefully bulletproof) logic that prevents it from throwing while being unwound, then your class behaves differently although the expectation would be that it works the same. You now need a separate way of detecting the error condition, or you must simply ignore the error. Either way, this stinks.

 

Or, you are unaware of what happens when you throw from a destructor during unwind, and do it anyway. This is even worse, in two respects (first, because you don't know the implications, and second because it actually happens, and the program is now in an undefined, unrecoverable state).

 

So, for that this case, crashing hard by terminating the program is a good thing. It forces the programmer to address the issue. Actually, the mere presence of a throw keyword inside a destructor should preferrably generate a build error, if you ask me.


#1samoth

Posted 20 August 2013 - 07:12 AM

Note that throwing an exception from a destructor is also super bad mojo in C++. Basically any exception guarantees go out the window if you have destructors that throw. It's sufficiently bad that C++11 gave all destructors an implicit noexcept exception specification, meaning that an exception from a destructor will immediately call terminate() unless you specifically enable exceptions for the destructor for the class or one of the subobjects of that class contains a destructor which has exception enabled destructors.

 

Actually I find this one of the more valuable additions to C++11, because if your destructor throws, something is seriously fucked up.

 

Either you have a "conditional destructor" with some (hopefully bulletproof) logic that prevents it from throwing while being unwound, then your class behaves differently although the expectation would be that it works the same. You now need a separate way of detecting the error condition, or you must simply ignore the error. Either way, this stinks.

 

Or, you are unaware of what happens when you throw from a destructor during unwind, and do it anyway. This is even worse, in two respects (first, because you don't know the implications, and second because it actually happens, and the program is now in an undefined, unrecoverable state).

 

So, for that this case, crashing hard by terminating the program is a good thing. It forces the programmer to address the issue. Actually, the mere presence of a throw keyword inside a destructor should preferrably generate a build error, if you ask me.


PARTNERS