By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,491 Members | 1,181 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,491 IT Pros & Developers. It's quick & easy.

Using "break" to Break Out of Multiple Loops in One Call

P: n/a
Does C# support anything like PHP's break command that optionally
accepts a parameter specifying how many loops to break out of?
Feb 15 '08 #1
Share this Question
Share on Google+
11 Replies


P: n/a
No - 'break' and 'continue' always apply to the innermost loop.
You will need to set and test flags to do what you want (or - gasp - goto).
--
http://www.tangiblesoftwaresolutions.com
C++ to C#
C++ to VB
C++ to Java
Instant C#: VB to C#
Instant VB: C# to VB
Instant C++: VB or C# to C++/CLI
Java to VB & C# Converter: Java to VB or C#
"O.B." wrote:
Does C# support anything like PHP's break command that optionally
accepts a parameter specifying how many loops to break out of?
Feb 15 '08 #2

P: n/a
On 15 Feb, 18:31, "O.B." <funkj...@bellsouth.netwrote:
Does C# support anything like PHP's break command that optionally
accepts a parameter specifying how many loops to break out of?
Not that Im aware of, and there would be grunts in the cleraing of
code if I found one...

for(;;int i(for(i=0;i<100;for(;console.writeline("{0}\n",i;f or(;;i+
+for(;;break(2))))));
have to try that... someday... it sholdnt work, but giving an example
of why not.. it should stop at writing nothing but who knows...
//CY
Feb 15 '08 #3

P: n/a
O.B. wrote:
Does C# support anything like PHP's break command that optionally
accepts a parameter specifying how many loops to break out of?
No. And that's not very nice to begin with (requiring the programmer to
count carefully). Labeled breaks a la Java would be better, but it doesn't
have that either.

If you really think it makes the code easier to read, you can always use
goto. If the "multi-level break" is to handle a rare error condition, you
could throw an exception instead. If that's the case, though, you should
probably split things up in multiple functions. That would also allow you to
use "return" to break out of all loops in the current function.

--
J.
Feb 15 '08 #4

P: n/a
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in
news:op***************@petes-computer.local:
Either way, I don't think there's anything inherently bad about
labeled "break" statements or "goto" statements. Sometimes they are
just what you need. Just remember not to aim at your foot when using
them. :)
There's nothing bad in goto. I just love the longjmp() !!
Feb 16 '08 #5

P: n/a
On Fri, 15 Feb 2008 17:26:49 -0800, Donkey Hot <sp**@plc.is-a-geek.com>
wrote:
There's nothing bad in goto. I just love the longjmp() !!
Well, sure. But these days we have exceptions to provide for that.

In fact, I'd say if anything, the descendant of longjmp() is much more
broadly accepted than that of goto. :)
Feb 16 '08 #6

P: n/a

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
Personally, I'm not of the mind that "goto" statements are inherently
bad. They certainly can be misused, and may well be misused much more
than other language constructs. But they also have their place (and I
don't just mean as a replacement for falling through in "case" statements
:) ).
Would you mind providing one such example?

Feb 16 '08 #7

P: n/a
On Sat, 16 Feb 2008 08:16:53 -0800, Scott Roberts
<sr******@no.spam.here-webworks-software.comwrote:
>
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
>Personally, I'm not of the mind that "goto" statements are inherently
bad. They certainly can be misused, and may well be misused much more
than other language constructs. But they also have their place (and I
don't just mean as a replacement for falling through in "case"
statements :) ).

Would you mind providing one such example?
Well, one common scenario is error-handling. In some cases, it makes
sense to have a single exit point in a method so that things can be
cleaned up in a single block of code rather than repeating that code, or
some subset, throughout the method. Using a "goto" statement allows you
to place that cleanup in a single place (I generally put it at the end of
the method), jumping to it on an error, and otherwise falling straight
through.

Nesting a bunch of "if()" statements can accomplish the same thing, but it
can create a difficult-to-read pattern of indentation. Using a "goto"
provides a lot of the same readability benefits that using exceptions for
failures can as well.

Are there other ways to do that? Sure, especially in C# (which has
"using" as well as exceptions). But those alternatives don't always
result in code that's as readable. And does the presence of those
alternatives mean that a "goto" statement is bad? No, not at all. Only
someone who had a blanket objection to using a "goto" statement for the
sake of the objection would say it was.

The fact is, even if you never write a "goto" statement, you use "goto"s
all the time. As long as you're keeping the code structured as you use a
"goto" statement, you haven't done anything the compiler wouldn't do
anyway. And if the use of the "goto" makes the code more readable, then
that's an advantage over shoe-horning your code into whatever alternative
the language would require to accomplish the same thing.

Pete
Feb 16 '08 #8

P: n/a
On Feb 16, 3:11 pm, "Scott Roberts" <srobe...@no.spam.here-webworks-
software.comwrote:
"Peter Duniho" <NpOeStPe...@nnowslpianmk.comwrote in message

news:op***************@petes-computer.local...
On Sat, 16 Feb 2008 08:16:53 -0800, Scott Roberts
<srobe...@no.spam.here-webworks-software.comwrote:
"Peter Duniho" <NpOeStPe...@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
Personally, I'm not of the mind that "goto" statements are inherently
bad. They certainly can be misused, and may well be misused much more
than other language constructs. But they also have their place (and I
don't just mean as a replacement for falling through in "case"
statements :) ).
Would you mind providing one such example?
I am not Peter Duniho but I can provide you an example from a real
world high-performance middle-ware product. I lifted this piece out
of the codebase of this product (http://www.zeroc.com)

Consider this snippet that listens on a socket:

public static void doListen(Socket socket, int backlog)
{
repeatListen:

try
{
socket.Listen(backlog);
}
catch(SocketException ex)
{
if(interrupted(ex))
{
goto repeatListen;
}

closeSocketNoThrow(socket);
throw new Ice.SocketException(ex);
}
}

public static bool interrupted(Win32Exception ex)
{
return ex.NativeErrorCode == WSAEINTR;
}

There are probably other ways to do this without using goto but you
will only end up obfuscating the intent of the code for some mythical
purity.

Feb 17 '08 #9

P: n/a

"Dilip" <rd*****@lycos.comwrote in message
news:00**********************************@p25g2000 hsf.googlegroups.com...
On Feb 16, 3:11 pm, "Scott Roberts" <srobe...@no.spam.here-webworks-
software.comwrote:
>"Peter Duniho" <NpOeStPe...@nnowslpianmk.comwrote in message

news:op***************@petes-computer.local...
On Sat, 16 Feb 2008 08:16:53 -0800, Scott Roberts
<srobe...@no.spam.here-webworks-software.comwrote:
>"Peter Duniho" <NpOeStPe...@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
Personally, I'm not of the mind that "goto" statements are inherently
bad. They certainly can be misused, and may well be misused much
more
than other language constructs. But they also have their place (and
I
don't just mean as a replacement for falling through in "case"
statements :) ).
>Would you mind providing one such example?

I am not Peter Duniho but I can provide you an example from a real
world high-performance middle-ware product. I lifted this piece out
of the codebase of this product (http://www.zeroc.com)

Consider this snippet that listens on a socket:

public static void doListen(Socket socket, int backlog)
{
repeatListen:

try
{
socket.Listen(backlog);
}
catch(SocketException ex)
{
if(interrupted(ex))
{
goto repeatListen;
}

closeSocketNoThrow(socket);
throw new Ice.SocketException(ex);
}
}

public static bool interrupted(Win32Exception ex)
{
return ex.NativeErrorCode == WSAEINTR;
}

There are probably other ways to do this without using goto but you
will only end up obfuscating the intent of the code for some mythical
purity.
Hmmm, here's my attempt, but you may be right. I'll admit that the original
is pretty good. Thanks for the example.

// The intent here should be pretty clear: keep calling
// "tryListen" until it returns "true". Although, it's not
// entirely clear *why* tryListen might return false.
public static void doListen(Socket socket, int backlog)
{
while (!tryListen(socket, backlog)) ;

// or

bool success = tryListen(socket, backlog);
while (!success)
success = tryListen(socket, backlog);
}

// The intent here may be a little obfuscated. It's not clear
// at all that you are going to retry if "interrupted".
public static bool tryListen(Socket socket, int backlog)
{
try
{
socket.Listen(backlog);
}
catch(SocketException ex)
{
if(interrupted(ex))
{
// Listen failed, try again.
return false;
}

closeSocketNoThrow(socket);
throw new Ice.SocketException(ex);
}

// Listen succeeded.
return true;
}

public static bool interrupted(Win32Exception ex)
{
return ex.NativeErrorCode == WSAEINTR;
}

Feb 17 '08 #10

P: n/a
Dilip wrote:
>
I am not Peter Duniho but I can provide you an example from a real
world high-performance middle-ware product. I lifted this piece out
of the codebase of this product (http://www.zeroc.com)

Consider this snippet that listens on a socket:

public static void doListen(Socket socket, int backlog)
{
repeatListen:

try
{
socket.Listen(backlog);
}
catch(SocketException ex)
{
if(interrupted(ex))
{
goto repeatListen;
}

closeSocketNoThrow(socket);
throw new Ice.SocketException(ex);
}
}

public static bool interrupted(Win32Exception ex)
{
return ex.NativeErrorCode == WSAEINTR;
}
Hmm, I didn't know you could jump out of a try block with a goto, then re-enter
the block, very interesting...

How about:

public static void doListen(Socket socket, int backlog)
{
bool retry = true;
while (retry)
{
try
{
socket.Listen(backlog);
retry = false;
}
catch(SocketException ex)
{
if (!interrupted(ex))
{
closeSocketNoThrow(socket);
throw new Ice.SocketException(ex);
}
}
}
}

Feb 17 '08 #11

P: n/a
Another situation is where a particular operation will invalidate the
data being processes. For instance
start:
Generate dataset

for( - data set - )
while (something something)
for( - dataset - )
if (something something)
{
something that invalidates dataset
goto start:
}

*** Sent via Developersdex http://www.developersdex.com ***
Feb 19 '08 #12

This discussion thread is closed

Replies have been disabled for this discussion.