www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Problem with allowing exceptions to be thrown from dtors

reply Sean Kelly <sean f4.ca> writes:
Currently, if an object's dtor throws an exception, its monitor data 
will not be cleaned up.  This can be seen in 
internal/gc/gc.d:_d_callfinalizer.  This problem has a simple 
solution--move the call to _d_monitorrelease inside the finally block 
following the call--however, this merely moves the problem to a new 
location: the garbage collector.  Currently, if an exception is thrown 
from a dtor called during a garbage collection cycle, the collection 
will end prematurely, potentially leaving the garbage collector in an 
invalid state.  This leaves the GC implementor with a host of 
unattractive options, the most obvious being:

* Attempt to make the collection cycle exception-safe so that integrity 
is retained if an exception is thrown from an object's dtor.

* If an exception is thrown, hold a reference to it until the end of 
collection and then rethrow, blindly hoping that the application is in a 
valid state and that no more dtors throw during the collection.

* Silently eat the exception and soldier on, again hoping the 
application is in a valid state.

I believe these options are all either prohibitively difficult or 
unreasonable and that the correct behavior should be to terminate the 
application either immediately via a system call or simply by rethrowing 
the user-level exception wrapped in something a bit less likely to be 
caught in user code (ie. something akin to an AssertException).  An 
alternative would be to simply make throwing an exception during a GC 
run illegal and allow it for explicit deletion, with the caveat that the 
object will not be fully collected and thus a resource leak will occur, 
but this doesn't seem a terribly attractive compromise.

I'm leaving this out of bugzilla for now because it's not exactly a bug, 
but I do believe it needs consideration before 1.0.


Sean
Apr 13 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Allowing an uncaught exception to escape a destructor is always a bad 
idea, and should be explicitly illegal.
Apr 15 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 Allowing an uncaught exception to escape a destructor is always a bad 
 idea, and should be explicitly illegal.

Works for me :-) Sean
Apr 15 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:

 Allowing an uncaught exception to escape a destructor is always a bad 
 idea, and should be explicitly illegal.

With function calls, DBC, ABC and the like to consider, how do you think you're going to get on with enforcing such legislation? Stewart.
Apr 16 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 
 Allowing an uncaught exception to escape a destructor is always a bad 
 idea, and should be explicitly illegal.

With function calls, DBC, ABC and the like to consider, how do you think you're going to get on with enforcing such legislation?

The same way C++ does - through documentation. I don't think there is any other way.
Apr 16 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 
 Allowing an uncaught exception to escape a destructor is always a bad 
 idea, and should be explicitly illegal.

With function calls, DBC, ABC and the like to consider, how do you think you're going to get on with enforcing such legislation?

Easy. In the runtime code that calls dtors. Most or all of this could be done by adding a few lines to _d_delclass. Sean
Apr 16 2006
parent Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:
 Stewart Gordon wrote:
 Walter Bright wrote:

 Allowing an uncaught exception to escape a destructor is always a bad 
 idea, and should be explicitly illegal.

With function calls, DBC, ABC and the like to consider, how do you think you're going to get on with enforcing such legislation?

Easy. In the runtime code that calls dtors. Most or all of this could be done by adding a few lines to _d_delclass.

Er... I meant _d_callfinalizer, but it amounts to tbe same thing. Sean
Apr 16 2006