Why finally?

[Ken]

What is the purpose of a finally block in try-catch-
finally? I am confused because, if I am reading the
definition correctly, this block seems unnecessary.
Consider the following from the Visual Studio
documentation. In the first foo(), the statement in the
finally block will execute even though there is an
exception in the try block. In the second foo(), I took
the statement out of the finally block but it should still
execute since it comes after the whole thing.

So... what is the difference between a "finally" block and
nothing at all?

void foo()
{
int i = 123;
string s = "Some string";
object o = s;

try
{
// Invalid conversion; o contains a string not an int
i = (int) o;
}
catch (Exception e)
{
Console.WriteLi ne("Exception!" );
}
finally
{
Console.Write(" i = {0}", i);
}
}

Now, consider something similar:

void foo()
{
int i = 123;
string s = "Some string";
object o = s;

try
{
// Invalid conversion; o contains a string not an int
i = (int) o;
}
catch (Exception e)
{
Console.WriteLi ne("Exception!" );
}

Console.Write(" i = {0}", i);
}

[Jon Skeet]

james <no****@hyperco n.net> wrote:

Yep, I guess I misread, I was thinking of return from finally.
Which by the way is kind of a pain not being able to do that.

Indeed. It would often be a mistake to do it, but it's occasionally
handy. (You can do it in Java, which is how I know it's handy sometimes
:)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Wim Hollebrandse]

So why would anyone want to return from within a finally block? Since
finally blocks are always executed, why not simply return after the full
try..catch...fi nally statement?

I suppose if you have so much logic in your finally block that you need to
return in some cases and not in others, it sounds like there's a problem
with the flow and design of the code.

Cheers,
Wim Hollebrandse
http://www.wimdows.com
http://www.wimdows.net

"Jon Skeet" <sk***@pobox.co m> wrote in message
news:MP******** *************** @news.microsoft .com...

james <no****@hyperco n.net> wrote:

Yep, I guess I misread, I was thinking of return from finally.
Which by the way is kind of a pain not being able to do that.

Indeed. It would often be a mistake to do it, but it's occasionally
handy. (You can do it in Java, which is how I know it's handy sometimes
:)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jon Skeet]

"Wim Hollebrandse" <wimATwimdows.c om> <"Wim Hollebrandse"
<wimATwimdows.c om>> wrote:

So why would anyone want to return from within a finally block? Since
finally blocks are always executed, why not simply return after the full
try..catch...fi nally statement?
Because you may have some conditional behaviour in the finally block -
and also potentially because you wish to return in order to override
any exception which may have occurred. For instance, you could have
something like:

object GetValue (object defaultValue)
{
object ret = defaultValue;

try
{
ret = AttemptToGetRea lValue();
}
finally
{
return ret;
}
}

Not something I'd often consider, admittedly (it masks too many
exceptions) - just an off-the-top-of-my-head example.
I suppose if you have so much logic in your finally block that you need to
return in some cases and not in others, it sounds like there's a problem
with the flow and design of the code.

There doesn't necessarily need to be *very* much logic in there. I'm
not saying I do it particularly often, but just occasionally it's
handy.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jay B. Harlow [MVP - Outlook]]

James,
Maybe its just me. :-) I would simply put the return in the try block.

Something like:

int value = y;
try
{
val = doSomthing();
if ( val == X )
return true;
else
return false;
}
catch ( exception e)
{
//handle it
}
finally
{
}
I would suspect the finally block was doing too much, if it needed to decide
what the return value was.

Hope this helps
Jay

"james" <no****@hyperco n.net> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. .. A more likely example is where the method return a boolean
like so
int value = y;
try
{
val = doSomthing();
}
catch ( exception e)
{
//handle it
}
finally
{
if ( val == X )
return true;
else
return false;
}

how can you be sure the proper return result is returned if
you do not catch the exception ??

JIM
"Jon Skeet" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@news.microsof t.com...

"Wim Hollebrandse" <wimATwimdows.c om> <"Wim Hollebrandse"
<wimATwimdows.c om>> wrote:

So why would anyone want to return from within a finally block? Since
finally blocks are always executed, why not simply return after the full try..catch...fi nally statement?
Because you may have some conditional behaviour in the finally block -
and also potentially because you wish to return in order to override
any exception which may have occurred. For instance, you could have
something like:

object GetValue (object defaultValue)
{
object ret = defaultValue;

try
{
ret = AttemptToGetRea lValue();
}
finally
{
return ret;
}
}

Not something I'd often consider, admittedly (it masks too many
exceptions) - just an off-the-top-of-my-head example.

I suppose if you have so much logic in your finally block that you need to

return in some cases and not in others, it sounds like there's a

problem with the flow and design of the code.

There doesn't necessarily need to be *very* much logic in there. I'm
not saying I do it particularly often, but just occasionally it's
handy.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jon Skeet]

Jay B. Harlow [MVP - Outlook] <Ja********@ema il.msn.com> wrote:

Maybe its just me. :-) I would simply put the return in the try block.
But then you've got to have another return statement either in the
finally block or after it, in case doSomething() throws an exception
which is caught.
I would suspect the finally block was doing too much, if it needed to
decide what the return value was.

Usually, yes - but *sometimes* it's handy.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jon Skeet]

Jay B. Harlow [MVP - Outlook] <Ja********@ema il.msn.com> wrote:

Lets says there is no exception, the program proceeds to the finally block,
sees the return statement that returns a value. That mostly makes sense.
Now lets say an exception was thrown, but is not caught!, the program
proceeds to the finally block, sees the return statement with a value. Huh!
I'm in the middle of raising an exception, do I evaluate the return and
return the value, or do I continue raising the exception. Seeing as the
exception has precedence I ignore the value on the return (it is evaluated,
just not used) and continue to raise the exception.

Not in Java, at least - and if C# had return in finally, I'd expect it
not to be true in C# either. The last reason for terminating the method
(return or exception) is the one that takes priority. I realise this is
all hypothetical, but where did you get the "seeing as the exception
has precedence" idea from?

Unfortunately it's relatively hard to find any occasions in my existing
code where I've used return from a finally block - if I run into any in
the next few days, I'll post them. I don't expect to though - as I say,
I've only used it occasionally.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jay B. Harlow [MVP - Outlook]]

Jon,

all hypothetical, but where did you get the "seeing as the exception
has precedence" idea from?
I was trying to say that:

If you entered the finally block because of an exception, the block is
operating in the context of an exception handler, a value on the return is
immaterial.

If you entered the finally block as normal program flow (no exception), the
block is operating in the context of not being an exception handler, a value
on the return is material.

As you put it, the last reason for terminating the method (implicit or
explicit) return or an exception.

Jay

"Jon Skeet" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@news.microsof t.com... Jay B. Harlow [MVP - Outlook] <Ja********@ema il.msn.com> wrote:

Lets says there is no exception, the program proceeds to the finally block, sees the return statement that returns a value. That mostly makes sense.
Now lets say an exception was thrown, but is not caught!, the program
proceeds to the finally block, sees the return statement with a value. Huh! I'm in the middle of raising an exception, do I evaluate the return and
return the value, or do I continue raising the exception. Seeing as the
exception has precedence I ignore the value on the return (it is evaluated, just not used) and continue to raise the exception.

Not in Java, at least - and if C# had return in finally, I'd expect it
not to be true in C# either. The last reason for terminating the method
(return or exception) is the one that takes priority. I realise this is
all hypothetical, but where did you get the "seeing as the exception
has precedence" idea from?

Unfortunately it's relatively hard to find any occasions in my existing
code where I've used return from a finally block - if I run into any in
the next few days, I'll post them. I don't expect to though - as I say,
I've only used it occasionally.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too