Problem with allowing exceptions to be thrown from dtors

[Sean Kelly]

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