break

Thread view:

Mike - 10 Apr 2007 04:44 GMT

Hi:

public class bbb
{
public static void main(String args[])
{
    System.out.println(sum(100000));
}
public static int sum(int n)
{
     if(n==0)
     break;
     else
    return sum(n-1)+n;
}
}

After I compiled the above program, error message shows " break
outside switch or loop".
Why?
Thank you in advance.
Mike

Reply to this Message

Tarkin - 10 Apr 2007 05:02 GMT

> Hi:
>
[quoted text clipped - 19 lines]
> Thank you in advance.
> Mike

Because the keyword [ break ] is only used
with looping constructs like
switch (..) { ...} , while (..) {...},
do {...} while (..) and for (...) {...} .

[switch-case is a single-iteration loop, as
is do {...} while(false) ]

AFAIK in Java, if (..) ... or if (..) {...}
does not count as a loop, thus you cannot use
break.

I believe you can code your construct in one
of two ways:

if (n != 0) ...

or

if (n == 0) {}
else {...}

The latter allows for slightly 'easier'
code addition later.

HTH,
Tarkin

Reply to this Message

Patricia Shanahan - 10 Apr 2007 05:49 GMT

> Hi:
>
[quoted text clipped - 16 lines]
> outside switch or loop".
> Why?

Because you have a break that is not in a switch or loop :-)

By definition "A break statement with no label attempts to transfer
control to the innermost enclosing switch, while, do, or for statement
of the immediately enclosing method or initializer block; this
statement, which is called the break target, then immediately completes
normally." That makes no sense at all if there is no enclosing switch,
while, do, or for statement in the method.

I don't know what you are trying to do, but my best guess from the look
of the code is that you want to return immediately from sum. You have to
return something, because sum returns int, and from the context it looks
as though 0 is the most reasonable thing:

if(n==0)
return 0;
else
return sum(n-1)+n;

Patricia

Reply to this Message

Mike - 10 Apr 2007 06:21 GMT

> > Hi:
>
[quoted text clipped - 39 lines]
>
> - Show quoted text -

Thank you very much.
Yes, I want to do a test study of sum by recursive.
I heard that it runs quite slowly when one use recursive.

Then why do people use recursive? On what situtation?
Is there an example that one must use it?

thank you

Mike

Reply to this Message

Daniel Pitts - 10 Apr 2007 06:56 GMT

> > > Hi:
>
[quoted text clipped - 50 lines]
>
> Mike

There are no situations where you MUST use recursion, however, there
are many circumstances in which is simplifies the implementation of
your algorithm.

for example:
public static <E extends Comparable<E>> void quickSort(List<E> list) {
if (list.isEmpty() || list.size() == 1) {
return;
}
final int partitionPoint = partition(list);
quickSort(list.subList(0, partitionPoint));
quickSort(list.subList(partitionPoint, list.length());
}

It is possible to replace this implementation to use an explicit
stack, however, that would add an extra layer of complication...
Internally, you're using the call stack so you don't need to be
explicit about it.

Reply to this Message

a24900@googlemail.com - 12 Apr 2007 07:13 GMT

On Apr 10, 7:56 am, "Daniel Pitts" <googlegrou...@coloraura.com>
wrote:

> There are no situations where you MUST use recursion, however, there
> are many circumstances in which is simplifies the implementation of
> your algorithm.

And there are good reasons to avoid recursion in production code.
Unless you have complete control over the data it opens opportunities
for DoS attacks. Without additional guarding input data can eat up all
your memory, slows down your system and finally crash the
application.

When you use an explicit stack you can easily put a limit to the stack
size and enforce it.

When you use the return stack you can control recursion depth by using
an additional recursion counter somewhere. But that is often
forgotten. Most algorithm textbooks don't demonstrate the problem, so
algorithms blindly copied from textbooks are a classic source of these
kind of bugs. And the code with a counter gets ugly. You either have
some external "global" variable and can forget about multithreading,
or you have to pass the counter down as argument.

Reply to this Message

Daniel Pitts - 12 Apr 2007 19:15 GMT

On Apr 11, 11:13 pm, "a24...@googlemail.com" <a24...@googlemail.com>
wrote:

> On Apr 10, 7:56 am, "Daniel Pitts" <googlegrou...@coloraura.com>
> wrote:
[quoted text clipped - 8 lines]
> your memory, slows down your system and finally crash the
> application.

Actually, threads have limited stack size, so you're more likely to
just get a StackOverflowError.

> When you use an explicit stack you can easily put a limit to the stack
> size and enforce it.
[quoted text clipped - 6 lines]
> some external "global" variable and can forget about multithreading,
> or you have to pass the counter down as argument.

In either case, you should always validate your input, regardless of
your implementation choice. If possible, you should validate your
input before you even get into the meat of the algorithm, so that the
program fails faster, rather than 30 minutes into a process getting an
exception.

Reply to this Message

Alex Hunsley - 12 Apr 2007 02:31 GMT

> Hi:
>
[quoted text clipped - 12 lines]
> }
> }

public static int sum(int n)
{
return n*(n+1)/2;
}

Reply to this Message

break

Free Magazines