Best way to exit (newbie)

[Craig]

I have some code

Is the finish statement the best to use if method is of the type void


private void btnSave_Click(object sender, System.EventArgs e)
{

//If something happens here exit code block
if((string)Session["RecordID"] == "0")
{
//Execute code here
}
else
{
Goto Finish: //Exit routine
}
//More code here

Finish:
{
}

}

 

[Jon Skeet [C# MVP]]

I have some code

Is the finish statement the best to use if method is of the type void

No - just return, with no return value:

return;

 

[Scott Roberts]

I have some code

Is the finish statement the best to use if method is of the type void


private void btnSave_Click(object sender, System.EventArgs e)
{

//If something happens here exit code block
if((string)Session["RecordID"] == "0")
{
//Execute code here
}
else
{
Goto Finish: //Exit routine
}
//More code here

Finish:
{
}

}

Well, it appears that the best thing to do would be to move "//More code
here" up underneath "//Execute code here". However, it appears that you are
simply trying to validate the value of "RecordID" prior to doing *anything*.
In that case, I've seen arguements for code along these lines:

private void btnSave_Click(object sender, System.EventArgs e)
{
// Check for valid method pre-conditions.
if ( (string)Session["RecordID"] != "0" )
return;

// Execute code here.
}

 

[Jon Skeet [C# MVP]]

Well, it appears that the best thing to do would be to move "//More code
here" up underneath "//Execute code here". However, it appears that you are
simply trying to validate the value of "RecordID" prior to doing *anything*.
In that case, I've seen arguements for code along these lines:

private void btnSave_Click(object sender, System.EventArgs e)
{
// Check for valid method pre-conditions.
if ( (string)Session["RecordID"] != "0" )
return;

// Execute code here.
}

Indeed - although I'd put braces round the return statement, never
using an "if" without braces

I know the reasoning behind the ideology of only having a single exit
point from any method, but:

a) There are almost always potentially multiple exit points if you
consider exceptions as exit points

b) It quite often gets in the way of readability to have to
artificially plough on to the end of the method when the path through
it has effectively finished. In particular, it can lead to code being
indented much further than it would otherwise need to be, occasionally
leaving you wondering why.

c) When methods are kept shorts, it should still be fairly easy to find
all the normal exit points anyway.

(I know you weren't promoting this ideology - I just thought it worth
mentioning.)

 

[Scott Roberts]

(I know you weren't promoting this ideology - I just thought it worth
mentioning.)

I do promote the "single exit point" ideology. However, like my other
ideologies, I seem to break it on occassion.

 

[Jon Skeet [C# MVP]]

I do promote the "single exit point" ideology. However, like my other
ideologies, I seem to break it on occassion.

I suspected you might follow it usually given the "I've seen arguments
for" line, but respected the fact that you hadn't actually been pushing
it in this case

Personally, I think it was much more important in C where you really
needed to make sure you'd cleaned up all the memory you'd allocated
etc.

 

[Steve Walker]

I suspected you might follow it usually given the "I've seen arguments
for" line, but respected the fact that you hadn't actually been pushing
it in this case

Personally, I think it was much more important in C where you really
needed to make sure you'd cleaned up all the memory you'd allocated
etc.

In moments of zealotry I've often been drawn to the

string Foo(int x)
{
string result;
switch(x)
{
case 1:
result = "one"
break;
case 2:
result = "two"
break;
.....
}
return result;
}

approach for the sake of a single exit point, but I'm not sure that it
always makes for more readable code. At least with a return statement
you know that there's nothing further to read for that particular code
path.

 

[Guest]

Personally, I think it was much more important in C where you really
needed to make sure you'd cleaned up all the memory you'd allocated
etc.

I've run into something similar in C#. we employ a transaction system
similar to .NET 2.0's TransactionScope within a 'using' block. and there had
been times where multiple exit points in a method sometimes cause problem for
us because someone, somewhere inevitably forgets to properly vote before
leaving the scope and causing a rollback that's quite difficulty to track
down at times.

 

[Guest]

I fully agree, Jon, (and others). When I started professional programming I
had some hesitation in using "break" and "return" statements. I got over that
hesitation, and have never looked back. For years i've used them as much as I
want, and never regretted it. They are usually more readable than flags and
nested conditionals. When we see a "return" we know for sure that that is the
end of the method.

 

[Scott Roberts]

c) When methods are kept shorts, it should still be fairly easy to find
all the normal exit points anyway.

Since this came up in another post, I just wanted to point out the "return"
does not mark an exit point.

public void MyUnnecessarilyComplexMethod()
{
// Do some stuff.
try
{
// Try to do some more stuff.

if (some_condition)
return; // This is not the end of execution in this method!!!

// Do some other stuff.
}
finally
{
// Do some finally stuff.
// This executes even if you "return" above.
}
}


Of course, this functionality is defined by the language and should be "well
known".

 

[Jon Skeet [C# MVP]]

Since this came up in another post, I just wanted to point out the "return"
does not mark an exit point.

Indeed - I nearly mentioned that based on someone else's example, but
thought I'd leave it. It always marks the *start* of an exit point
though

Of course, this functionality is defined by the language and should be "well
known".

Indeed - and finally blocks should rarely be particularly involved. It
helps that in C#, you can't explicitly return from a finally statement,
so you can't change the return value to complicate things.