¿Por qué usar try {} finally {} con un bloque try vacío?

Noté que en System.Threading.TimerBase.Dispose()el método hay un try{} finally{}bloque pero try{}está vacío.

¿Hay algún valor en usar try{} finally{}con un vacío try?

http://labs.developerfusion.co.uk/SourceViewer/browse.aspx?assembly=SSCLI&namespace=System.Threading&type=TimerBase

[ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)]
internal bool Dispose(WaitHandle notifyObject)
{
    bool status = false;
    bool bLockTaken = false;
    RuntimeHelpers.PrepareConstrainedRegions();
    try {
    }
    finally {
        do {
            if (Interlocked.CompareExchange(ref m_lock, 1, 0) == 0) {
                bLockTaken = true;
                try {
                    status = DeleteTimerNative(notifyObject.SafeWaitHandle);
                }
                finally {
                    m_lock = 0;
                }
            }
            Thread.SpinWait(1);
            // yield to processor
        }
        while (!bLockTaken);
        GC.SuppressFinalize(this);
    }

    return status;
}

De http://blog.somecreativity.com/2008/04/10/the-empty-try-block-mystery/ :

Esta metodología protege contra una llamada Thread.Abort que interrumpe el procesamiento. La página de MSDN de Thread.Abort dice que "Los bloques no ejecutados finalmente se ejecutan antes de que se cancele el hilo". Por lo tanto, para garantizar que su procesamiento finalice, incluso si su hilo se interrumpe en el medio por alguien que llama a Abortar en su hilo, puede colocar todo su código en el bloque finalmente (la alternativa es escribir código en el bloque "catch" para determine dónde estaba antes de que Abort interrumpiera el "intento" y proceda desde allí si lo desea).

Esto es para evitar Thread.Abortinterrumpir un proceso. La documentación para este método dice que:

Finalmente, los bloques no ejecutados se ejecutan antes de que se cancele el subproceso.

Esto se debe a que para recuperarse con éxito de un error, su código deberá limpiarse después de sí mismo. Dado que C # no tiene destructores de estilo C ++, finallyy los usingbloques son la única forma confiable de garantizar que dicha limpieza se realice de manera confiable. Recuerde que el usingbloque se convierte en esto por el compilador:

try {
    ...
}
finally {
    if(obj != null)
        ((IDisposable)obj).Dispose();
}

En .NET 1.x, existía la posibilidad de que el finallybloque se abortara. Este comportamiento se cambió en .NET 2.0.

Además, tryel compilador nunca optimiza los bloques vacíos .