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:
{
}

}

Craig <(E-Mail Removed)> wrote:
> 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;

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

"Craig" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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.
}

Scott Roberts <(E-Mail Removed)> wrote:
> 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.)

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

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

Scott Roberts <(E-Mail Removed)> wrote:
> > (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. :-)

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.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

In message <(E-Mail Removed)>, Jon Skeet
<?@pobox.com.invalid> writes
>Scott Roberts <(E-Mail Removed)> wrote:
>> > (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. :-)
>
>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.

--
Steve Walker

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

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.

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

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