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

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

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

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.

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.

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 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