Perché usare try {} finalmente {} con un blocco try vuoto?

Ho notato che System.Threading.TimerBase.Dispose()il metodo ha un try{} finally{}blocco ma try{}è vuoto.

C'è valore nell'usare try{} finally{}con un vuoto 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;
}

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

Questa metodologia protegge da una chiamata Thread.Abort che interrompe l'elaborazione. La pagina MSDN di Thread.Abort dice che "I blocchi infine non eseguiti vengono eseguiti prima che il thread venga interrotto". Quindi, al fine di garantire che la tua elaborazione finisca anche se il tuo thread viene interrotto nel mezzo da qualcuno che chiama Abort sul tuo thread, puoi inserire tutto il tuo codice nel blocco finally (l'alternativa è scrivere il codice nel blocco "catch" in determinare dove eri prima che "provare" fosse interrotto da Abort e procedere da lì se si desidera).

Questo per evitare l' Thread.Abortinterruzione di un processo. La documentazione per questo metodo dice che:

I blocchi infine non eseguiti vengono eseguiti prima che il thread venga interrotto.

Questo perché al fine di recuperare correttamente da un errore, il codice dovrà essere pulito dopo se stesso. Poiché C # non ha distruttori in stile C ++ finallye i usingblocchi sono l'unico modo affidabile per garantire che tale pulizia venga eseguita in modo affidabile. Ricorda che il usingblocco si trasforma in questo dal compilatore:

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

In .NET 1.x, c'era la possibilità che il finallyblocco venisse interrotto. Questo comportamento è stato modificato in .NET 2.0.

Inoltre, i tryblocchi vuoti non vengono mai ottimizzati dal compilatore.