Why use try {} finally {} with an empty try block?

I noticed in `System.Threading.TimerBase.Dispose()` the method has a `try{} finally{}` block but the `try{}` is empty.

Is there any value in using `try{} finally{}` with an empty `try`?

[To see links please register here]

[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;
}

This is to guard against `Thread.Abort` interrupting a process. [Documentation][1] for this method says that:

> Unexecuted finally blocks are executed before the thread is aborted.

This is because in order to recover successfully from an error, your code will need to clean up after itself. Since C# doesn't have C++-style destructors, `finally` and `using` blocks are the only reliable way of ensuring that such cleanup is performed reliably. Remember that `using` block turns into this by the compiler:

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

In .NET 1.x, there was a chance that `finally` block will get aborted. This behavior was changed in .NET 2.0.

Moreover, empty `try` blocks never get optimized away by the compiler.


[1]:

[To see links please register here]

From [

[To see links please register here]

][1]:

> This methodology guards against a
> Thread.Abort call interrupting the
> processing. The MSDN page of
> Thread.Abort says that “Unexecuted
> finally blocks are executed before the
> thread is aborted”. So in order to
> guarantee that your processing
> finishes even if your thread is
> aborted in the middle by someone
> calling Abort on your thread, you can
> place all your code in the finally
> block (the alternative is to write
> code in the “catch” block to determine
> where you were before “try” was
> interrupted by Abort and proceed from
> there if you want to).


[1]:

[To see links please register here]