2 Answers
2

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).

Because that wasn't available until .NET 2.0
–
Hans PassantFeb 2 '10 at 18:22

@RobFonseca-Ensor: Because Thread.BeginCriticalRegion() does not prevent a thread from being aborted, rather tells the runtime that if a thread is aborted, then global state is corrupt, and the whole appdomain is up to a mercy killing.
–
kkmDec 5 '14 at 23:15

@HansPassant: BeginCriticalSection() really was not there in .NET 1.x, but there is no cause and effect, that you imply in saying because. In fact, in .NET 1.x, even a finally block could have been interrupted by a thread abort. These mechanisms serve a different purpose: doing work in a finally prevents aborting mid-way in code, while BeginCriticalSection() only declares to the runtime that the global state is at risk.
–
kkmDec 5 '14 at 23:19

This is to guard against Thread.Abort interrupting a process. Documentation 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.