Pourquoi utiliser try {} enfin {} avec un bloc try vide?

J'ai remarqué que System.Threading.TimerBase.Dispose()la méthode a un try{} finally{}bloc mais le try{}est vide.

Y a-t-il une valeur à utiliser try{} finally{}avec un vide 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;
}

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

Cette méthodologie protège contre un appel Thread.Abort interrompant le traitement. La page MSDN de Thread.Abort indique que «les blocs non exécutés sont finalement exécutés avant que le thread ne soit abandonné». Ainsi, afin de garantir que votre traitement se termine même si votre thread est abandonné au milieu par quelqu'un appelant Abort sur votre thread, vous pouvez placer tout votre code dans le bloc finally (l'alternative est d'écrire du code dans le bloc «catch» pour déterminez où vous vous trouviez avant que «l'essai» ne soit interrompu par Abort et poursuivez à partir de là si vous le souhaitez).

Il s'agit de se prémunir contre l' Thread.Abortinterruption d'un processus. La documentation de cette méthode indique que:

Enfin, les blocs non exécutés sont exécutés avant l'abandon du thread.

En effet, afin de récupérer avec succès après une erreur, votre code devra être nettoyé après lui-même. Étant donné que C # n'a pas de destructeurs de style C ++, finallyet les usingblocs sont le seul moyen fiable de garantir que ce nettoyage est effectué de manière fiable. N'oubliez pas que le usingbloc se transforme en ceci par le compilateur:

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

Dans .NET 1.x, il était possible que le finallybloc soit abandonné. Ce comportement a été modifié dans .NET 2.0.

De plus, les tryblocs vides ne sont jamais optimisés par le compilateur.