Exceptions during Finalize(): what methodology are

Question

I am developing a pretty extensive system in .NET, which involves a lot of system programming. Most time, I'm using the IDisposable pattern to handle resource disposal, but sometimes this isn't applicable (or left out by mistake) and resource gets destroyed during Finalize(). This might happen in COM interop, or when destructor calls Dispose() and there is an exception inside of it.

Basically: it is not always possible to clearly see and handle each scenario when finalizer might throw. And when it happens, the application will most certainly crash.

The reason why I'm concerned with specifically this class of problems is that finalizers are not called by a thread that created or used an object, so it is almost impossible task to tie the exception to the context in which the object was created. All you are getting is some generic GC thread.

So, question to the public now: if you account for those kind of issues, what do you do to control them? Tag the objects? Use a 3rd party tool which allows tracking those issues?

Also: is it possible to trigger some sort of global "Finalizer threw" event, to at least log that this very problem has happened?

EDIT1: Many thanks to everyone who submitted valuable input, I think I'm somewhat clearer now on what needs to be done. Last thing I would really like to get from this discussion is if somebody knows the methodology to trigger code on exception in finalizer (even if app crash is still inevitable), so that I could at least log it, without having to modify destructor of every class.

Answer 1

Your question is based on a somewhat faulty premise, that is it's not possible to to handle each scenario where a Finalizer might throw. This is precisely what you need to achieve here. Exceptions which occur during finalization will kill the process. Unless the exception is truly fatal, in which case let the program crash, you should be handling this exception in a manner that will not crash your program.

Having a Finalizer throw is almost as bad as having C++ destructors throw. Most implementations of IDisposable call into the same method for both active (IDisposable.Dispose()) and passive (finalizer thread) dispose operations. If the Finalizer version is throwing then it's likely or possible that the active dispose could throw as well. This, much like a C++ destructor throwing, will prevent nested resources from being disposed properly in certain cases.

Don't allow exceptions to propagate from a finalizer unless they are truly fatal to your application.

Answer 2

Finalizers are only needed in .NET for classes that directly own unmanaged resources (i.e. not only via an IDisposable member). Such classes must implement IDisposable using the standard pattern as described in MSDN.

The finalizer should only ever dispose unmanaged resources - the usual pattern is to call a method "protected void Dispose(bool disposing)" with the disposing argument set to false.

This method is typically implemented something like:

protected void Dispose(bool disposing)
{
    if (disposing)
    {
        // Dispose managed resources here.
        // (e.g. members that implement IDisposable)
        // This could throw an exception, but will *not* be called from the finalizer
        ...

    }
    ... Dispose unmanaged resources here.
    ... no need for any exception handling.
    ... Unlikely to get an exception, and if you do it will be fatal.
}

Since you are only ever disposing unmanaged resources, you generally should not be referencing any managed objects and shouldn't need to include any exception handling.

Answer 3

Apache DBCP, when dealing with abandoned connections, seems to generate an exception when a connection is opened, in order to store the stack trace and spit it out when it cleans up the connection. For resources that are not being disposed properly, you might try using a technique like this to track how the resource is initialized and used, so that the finalize method can produce useful error output.

Answer 4

I do the following in my classes, so in debug builds, I can try to catch these type of things.

In debug builds, an assertion is done to ensure the class was explictly disposed. Another assertion is done to make sure the finalizer doesn't throw. In release/production builds, this check is not performed to improved performance.

C# code

using System;
using System.Diagnostics;

namespace ConsoleApplication8
{
    class Program
    {
        class IReferenceUnmanagedMem : IDisposable
        {
#if(DEBUG)
            private static readonly string _ctorStackTrace = Environment.StackTrace;
#endif

            public IReferenceUnmanagedMem()
            {
            }

            ~IReferenceUnmanagedMem()
            {
#if(DEBUG)
                Debug.Fail("Dispose method not called.", _ctorStackTrace);
                try
                {
#endif
                    Dispose(true);
#if(DEBUG)
                }
                catch(Exception e)
                {
                    Debug.Fail("Dispose method threw exception in finalizer.", e.ToString());
                }
#endif
            }

            public void Dispose()
            {
                Dispose(false);
                GC.SuppressFinalize(this);
            }

            protected virtual void Dispose(bool inFinalizer)
            {
                if(inFinalizer)
                {
                    throw new Exception("I Know, this is a no-no.");
                }
            }
        }

        public static void Main()
        {
            IDisposable disposable = new IReferenceUnmanagedMem();
            disposable = null;
            GC.Collect();
            GC.WaitForPendingFinalizers();
        }
    }
}