• Sean Kelly (29/29) Apr 13 2006 Currently, if an object's dtor throws an exception, its monitor data
• Walter Bright (2/2) Apr 15 2006 Allowing an uncaught exception to escape a destructor is always a bad
• Sean Kelly (3/5) Apr 15 2006 Works for me :-)
• Stewart Gordon (4/6) Apr 16 2006 With function calls, DBC, ABC and the like to consider, how do you think...
• Walter Bright (3/10) Apr 16 2006 The same way C++ does - through documentation. I don't think there is
• Sean Kelly (4/11) Apr 16 2006 Easy. In the runtime code that calls dtors. Most or all of this could
• Sean Kelly (3/14) Apr 16 2006 Er... I meant _d_callfinalizer, but it amounts to tbe same thing.

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

Walter Bright <newshound digitalmars.com> writes:

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

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

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.

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.

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

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