Exit Sub in C#

[Tina]

In vb.net to get out of a sub or a function we can say Exit Sub. How can I
get out of a void method in C#. I can't find that documented anywhere.

Thanks,
T

 

[JimD]

In vb.net to get out of a sub or a function we can say Exit Sub. How can I
get out of a void method in C#. I can't find that documented anywhere.

Thanks,
T

return;

Jim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
There's no place like 127.0.0.1
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
JimD
Central FL, USA, Earth, Sol

 

[Yury]

use return.

Example:

void SomeMethod(){
if (condition)
return;
else
DoSmth()
}

 

[Barry Kelly]

In vb.net to get out of a sub or a function we can say Exit Sub. How can I
get out of a void method in C#. I can't find that documented anywhere.

return

-- Barry

 

[Guest]

in C# you use 'return'.

Actually, Exit Sub is deprecated in vb.net. You should be using return
there too.

Jeff

 

[Mark Rae]

In vb.net to get out of a sub or a function we can say Exit Sub. How can
I get out of a void method in C#. I can't find that documented anywhere.

You use return; same as you should be using in VB.NET. "Exit Sub", like "On
Error..." etc, is legacy VB code and is deprecated in VB.NET

 

[Paul Cheetham]

As you may have gathered - return will do the trick.

However, it is generally considered bad practice to have multiple exit
points for a function, and can make it harder to follow. So try not to
put any return statements in except at the end of the function.
I have not yet come across a situation where this is not possible.

i.e. Instead of :

if (condition)
return;
else
DoStuff()

Use :

if (!condition)
DoStuff()


Paul

 

[Larry Lard]

You use return; same as you should be using in VB.NET. "Exit Sub", like "On
Error..." etc, is legacy VB code and is deprecated in VB.NET

Do you have a reference for that? (about Exit; I agree about On Error)

 

[Peter Kirk]

However, it is generally considered bad practice to have multiple exit
points for a function, and can make it harder to follow. So try not to put
any return statements in except at the end of the function.
I have not yet come across a situation where this is not possible.

i.e. Instead of :

if (condition)
return;
else
DoStuff()

Use :

if (!condition)
DoStuff()

But are there not occasions where it is simpler and cleaner to have mulitple
returns? What about if you have to loop through a list or something, to find
a prticular object - if you find it you return it, if not you want to do
something else. Why not just have a return at the point in the loop where
you find the object, instead of breaking from the loop, checking if you
found the object and then returning it, or doing something else if you
didn't find it.

Ok, I'm not entirely sure that example is perfect, but is it true a blanket
"only one return" is valid?

 

[Paul Cheetham]

But are there not occasions where it is simpler and cleaner to have mulitple
returns? What about if you have to loop through a list or something, to find
a prticular object - if you find it you return it, if not you want to do
something else. Why not just have a return at the point in the loop where
you find the object, instead of breaking from the loop, checking if you
found the object and then returning it, or doing something else if you
didn't find it.

Ok, I'm not entirely sure that example is perfect, but is it true a blanket
"only one return" is valid?

It can look simpler and cleaner sometimes, but it makes it more
difficult to debug - especially if you come back to it after some length
of time, or somebody else has to try and do it.
It's perfectly valid and legal code, it just tends to be frowned on.

I usually declare a variable RetVal at the start of the function, as the
same return type as the function. I initialise it to the default return
value (usually that to signify the function has failed)
The last line is return (RetVal);

Using your loop example:

ListObj RetVal = null;

while (ListPos < ListCount && RetVal == null)
{
if (List[ListPos].ID == FindID)
RetVal = List[ListPos];
ListPos++;
}

return (RetVal)



Paul

 

[Mark Rae]

Do you have a reference for that? (about Exit; I agree about On Error)

Sorry, got myself slightly confused (I really never use VB / VB.NET these
days). I was aware that there was some difference to do with Return in the
latest version, but it seems that the GoSub reserved word has now been
deprecated, not the Exit reserved word - sorry for the misleading
information.

This is straight out of MSDN...

In a Sub or Set procedure, the Return statement is equivalent to an Exit Sub
or Exit Property statement, and expression must not be supplied.

In a Function, Get, or Operator procedure, the Return statement must include
expression, and expression must evaluate to a data type that is convertible
to the return type of the procedure. In a Function or Get procedure, you
also have the alternative of assigning an expression to the procedure name
to serve as the return value, and then executing an Exit Function or Exit
Property statement. In an Operator procedure, you must use Return
expression.

You can include as many Return statements as appropriate in the same
procedure.

 

[Bruce Wood]

I tend to agree with Peter on this one. I remember the "only have a
single return point" from the days of "proveable correctness." I
thought that the "only one return" edict had since been relegated to
the "preferable but not necessary" file. Maybe not. Personally, I find
the code you wrote more difficult to understand / debug / maintain than
this:

foreach (ListObj obj in List)
{
if (obj.ID == FindID)
{
return obj;
}
}
return null;

One less variable, one less test in the loop, no chance that I'll
forget the increment at the end of the loop... overall I find it much,
much simpler.

But then, that may be just me.

 

[james.curran]

I'm (mostly) with Peter & Bruce on this one. My rule: If the two
methods are functionally equlavent (such as in Paul's first example),
go with the single return. If the single-return requires any extra
code (such as in Paul's second example), go with the multiple returns.

 

[Bruce Wood]

In Paul's first example, I too consider it better form to reverse the
condition and avoid the additional return statement.

 

[Jon Skeet [C# MVP]]

As you may have gathered - return will do the trick.

However, it is generally considered bad practice to have multiple exit
points for a function, and can make it harder to follow. So try not to
put any return statements in except at the end of the function.
I have not yet come across a situation where this is not possible.

Well, it's considered bad practice by some. I find it can make life a
*lot* simpler - you can easily tell that you're "done" with a method,
rather than having to then *optionally* continue. You can end up with
horribly tortuous methods with extra variables existing just to work
out whether or not we already know the answer.

I would suggest people should try to put the return statements wherever
it makes the code simplest. IMO, this is usually at the first point
where you know what the result will be, unless you need to do any
"tidying up".

 

[Jon Skeet [C# MVP]]

In Paul's first example, I too consider it better form to reverse the
condition and avoid the additional return statement.

Actually, in Paul's first example I think it makes it more obvious that
the entire work of the method is done by having the extra return.
However, I wouldn't include the "else". I'd do:

if (weAreAlreadyDone)
{
return;
}

DoExtraStuff();

One advantage of this is that you end up with one level of indentation
fewer. It's not uncommon for there to be a few points at which the work
of the method can be finished so we can return early. With Paul's
suggestion, each of those would add an extra level of indentation. That
makes it harder to read, IMO.

 

[Tina]

Wow, I guess I started a religious "return debate". Actually return; was
the first thing I tried
but the compiler flagged it. I find that in C# the compiler will
occasionally flag something as an
error that is not an error. But then when something else is changed, that
is seemingly unrelated, the
flag goes away. This has happend four or five times.

The flag on the return; (the only error left) went away when I tightened up
some white space.

VB never did that.

thanks,
T

 

[james.curran]

I find that in C# the compiler will occasionally flag something as an error that is not an error. But then when something else is changed, that is seemingly unrelated, the flag goes away. This has happend four or five times. <<

I have never seen that happen, and seriously doubt it is in fact
happening. Now, sometimes the error is flagged some distance from
where the actual error occurred, mainly because the real error is an
acceptable syntax for something else, but that interpretation becomes
untennable a bit later on.
Consider the following:
public int Func(int a, int b)
{
if (a==b)
{
Console.WriteLine("Equals");

return a+b;
}

Now, you may realize that it's missing a closing paren after the
WriteLine, but the compiler is happy to accept the paren after the
return in it's place. It will finally complain about the missing
closing paren some lines later, with it finally runs out of them.

 

[Bruce Wood]

The flag on the return; (the only error left) went away when I tightened up some white space.

VB never did that.

C# doesn't do that either. I strongly suspect that something else
happened there.

 

[Steve]

Wow, I guess I started a religious "return debate". Actually return; was
the first thing I tried
but the compiler flagged it. I find that in C# the compiler will
occasionally flag something as an
error that is not an error. But then when something else is changed, that
is seemingly unrelated, the
flag goes away. This has happend four or five times.

The flag on the return; (the only error left) went away when I tightened up
some white space.

VB never did that.

thanks,

Hi Tina

I think the first thing you should do is forget about what vb does or
doesn't do. C# is a different language and the editor for each
language behave differently to each other.

Each language evolved from a different idea of how a language should
be implemented. They now use the same framework as you know but that
is a relatively recent development. I doubt you find irritation in
the differences between vb and cpp for instance, you expect there to
be. So it's the same with c#.

Whenever I code I get errors occurring that seem unrelated to the
actual problem itself.

eg

class test1
{

abc

public void Func()
{
// do stuff
}

}

an error will be flagged on public because the previous line is
invalid for several reasons.

if I add a ; to the end

abc;

the error moves to the ; telling me I have an invalid token. Obviously
the line terminator isn't an invalid token so the error is somewhere
else. Then changing the declaration to.

private int abc;

fixes the error.

One thing I've learnt is that when there is an error, no matter how
much I think it is with the tool I'm using or language I'm writing in,
99.9% of the time the mistake is mine and I probably need to check
what I've done or do a little more research so I'm more familiar with
the tools I'm using.

cheers

Steve

http://pretty-vacant.co.uk