Por que usar try {} finalmente {} com um bloco try vazio?

Eu notei em System.Threading.TimerBase.Dispose() método que tem um try{} finally{}bloco, mas o try{}está vazio.

Existe algum valor em usar try{} finally{} com um vazio 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/ :

Essa metodologia protege contra uma chamada Thread.Abort que interrompe o processamento. A página MSDN do Thread.Abort diz que "Finalmente os blocos não executados são executados antes que o segmento seja abortado". Portanto, para garantir que seu processamento seja finalizado, mesmo que seu thread seja interrompido no meio por alguém chamando Abort, você pode colocar todo o seu código no bloco final (a alternativa é escrever o código no bloco "catch" para determine onde você estava antes de "tentar" ser interrompido pelo Abortar e prossiga a partir daí, se desejar).

Isso é para evitar a Thread.Abortinterrupção de um processo. A documentação para este método diz que:

Finalmente, blocos não executados são executados antes que o encadeamento seja abortado.

Isso ocorre porque, para recuperar com êxito de um erro, seu código precisará ser limpo depois de si mesmo. Desde C # não tem C ++ - destruidores de estilo, finallye usingblocos são a única maneira confiável de garantir que tal limpeza é realizada de forma confiável. Lembre-se de que o usingbloco se transforma nisso pelo compilador:

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

No .NET 1.x, havia uma chance de o finallybloco ser abortado. Esse comportamento foi alterado no .NET 2.0.

Além disso, os tryblocos vazios nunca são otimizados pelo compilador.