[RESOLVED] Finally block

Hi,

Scenario:
I build a UDP connection.
Within a try{} block I connect, send and receive.
Now on exceptions or invalid messages, I 'return' an error code, thus effectively exiting the method.
To clean up the connection, I want to close it.

The question here is whether I should close it before every 'return' action, or simply close it in the finally{} block.

I made the following test-case, but I'm wondering whether this is a reliable test.

Code:

---

                static void Main(string[] args)
                {
                        try
                        {
                                //throw new IndexOutOfRangeException();
                                return;
                        }
                        catch (IndexOutOfRangeException)
                        {
                                return;
                        }
                        finally
                        {
                                Console.WriteLine("Reached finally");
                                Console.Read();
                        }
                }

---

The result of this test is that it writes 'Reached finally' whether I throw an exception or just 'return'.

I'm just a bit surprised that even if I return, it runs the finally{} block.
Is this expected behavior?

Thanks.

I'm not sure why you're surprised... as the finally block runs no matter what...that's part of the point of the finally block... gives the developer a chance to clean things up before the process exits. the documentation tells you this.

Now... your return... I'm a little surprised that throwing in the return in the catch didn't throw up a warning or error... I may be a stickler for such things, but returning out of an error handler like that I consider bad form. Although looking at your example I see that it is a contrived situation. But I subscribe to the single entry single exit design when it comes to functions.

-tg

Single Entry Single Exit is so 80s. =)

I would (and do) do exactly as BigBig whipped up.

And yes, finally is created specifically so that you can ensure objects are cleaned up no matter success or failure - it doesn't matter if you indicate that you're returning - it'll clean up and then return.

Uh huh... mkay... what ever. More like it's so 60's, 70's, 80's, 90's, 00's .... and for a good reason... but hey, what ever boats your float.

-tg

I'm not dissing you. I promise! I was just trying to insert some friendly elbowing.

There are different philosophies to coding. But at the level of programming languages that .Net (and Java and most true OO languages) are at, the benefits from single entry / exit are usually not realized in the same ways they used to be. Especially when you consider that in order to accomodate single entry / exit you usually have to use booleans and if statements.

But it's not wrong and I would never say it is - to subscribe to single entry / exit.

Hell I have some hold over traits that people would argue aren't needed any more either. Prefixing variables is one.

Often in my code you'll see stuff like:

string sName
int iCount
etc.

Many people would point out that these days it's too easy to know what types objects are and often the name itself hints. They'd be right, but that won't stop me from prefixing. I like it, I find value in it. And if it too is so 80s, I'm sticking with it!

So in short, I meant no offense. =)

one of the reasons I'm an advocate of the single entry/exit is to avoid the exact confusion like what the OP was asking about... if I return from my catch.... what happens to the finally block? Plus, I find it easier to debug when trying to figure out what value is being returned by a function... I can set a breakpoint on the one return statement and get and exact value that's being returned (more often than not when multiple returns are used, there's an expression, which semi-hides the actual value being returned).

Plus everywhere I've been has also subscribed to the se/se methodology.

When it comes to prefixing, that was a habit I've easily given up... with two exceptions... I still prefix my internal private members with an underscore... and I've taken to prefixing my form controls with "ux" .... and I still CAPSMYCONSTANTS ... the day I give that up will be when they pry the keyboard from my cold dead hands. I plan to die at the keyboard. The last thing I'll write will be:

Code:

---

Me.End
Me.Dispose

---

The only point I was trying to make is that it's (se/se) something that's been around for a long time, surely there must be a reason for it... then again... vacuum tubes have been around for a long time too, but we gave those up as well. =:-)

-tg

Thanks for the replies.

I'm applying this in a larger method and it does have several exit points.
That's mainly because the method returns a different error code at each point it fails.
Of course I could go 'single entry - single exit', but it would require excessive 'if'-statements I think.
Anyway, it works, that's the important part :D