Problem with allowing exceptions to be thrown from dtors
sean at f4.ca
Thu Apr 13 19:01:49 PDT 2006
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.
More information about the Digitalmars-d-bugs