Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[tlug] [OT] C# question -- try / catch / finally



Hi all,

Way off-topic, I know, but there are some coders hanging out here and
I'm hoping one of you will be able to answer this.

So, I'm learning about C# and the .NET framework while developing for
Windows Phone 8. Not my choice, but hey, you do what's asked of you if
you want to keep your job, right?

I'm not that wet behind the ears that I don't know about exception
handling, it's this curious "finally" block that has me stumped. I can
see how it works but I really can't see the point in it.

Given this snippet of code:

try {
  doSomething();
  doSomethingElse();
  areWeDoneAlready();
}
catch (SomeKindOfException) {
  kaboom();
}
finally {
  cleanup();
}

If doSomething() executes fine with no exceptions being raised then
execution goes on to doSomethingElse() and then areWeDoneAlready(), then
jumps straight to the finally block and cleanup() is executed.

If, however, doSomething() does raise SomeKindOfException then execution
is transferred immediately to the relevant catch block and kaboom() is
executed before the finally block is.

If the finally block is executed in both cases, whether the exception is
thrown or not, what is the point in having a special construct for it at
all? Surely this is functionally equivalent:

try {
  doSomething();
  doSomethingElse();
  areWeDoneAlready();
}
catch (SomeKindOfException) {
  kaboom();
}
cleanup();

Is there any type of circumstance where a finally block actually brings
something to the table?

-- 
Godwin Stewart -- <gstewart@example.com>


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links