...
>> Each continue effectively jumps to its loop's while expression
>> evaluation.
>
> And both "continue"s are unnecessary, since evaluating the "while" is the
> next thing to be done anyway, making mw wonder what the intention of the
> code is.
I assumed it was an artificial test case, stripped down from a larger
program. I THINK maybe the OP expected the continue to unconditionally
go on to another iteration, regardless of the while. That would not be
equivalent to falling through to the while.
Patricia
Mike Schilling - 10 Aug 2006 08:29 GMT
> ...
>>> Each continue effectively jumps to its loop's while expression
[quoted text clipped - 8 lines]
> go on to another iteration, regardless of the while. That would not be
> equivalent to falling through to the while.
I'm not sure why they were there, which is why I thought it worth pointing
out that they did nothing.
emrefan - 10 Aug 2006 09:03 GMT
> > ...
> >>> Each continue effectively jumps to its loop's while expression
[quoted text clipped - 11 lines]
> I'm not sure why they were there, which is why I thought it worth pointing
> out that they did nothing.
I used such a do loop construct because that I was what I found while
googling. Didn't realize I could do without the label. Now that I've
given it a thought, I guess maybe some people want to use a label to
show what is being continued. I personally would have used a comment
after the "continue" to get the same readability result if I had known
that the label wasn't necessary.
emrefan - 10 Aug 2006 08:55 GMT
> ...
> >> Each continue effectively jumps to its loop's while expression
[quoted text clipped - 8 lines]
> go on to another iteration, regardless of the while. That would not be
> equivalent to falling through to the while.
You are right, what I posted was just a test program to illustrate a
point. And you guessed right, I did expect the continue to
unconditionally go on to another iteration.
Searched the net for a replacement goto construct in java and I found
that "There: do { ... continue There } while (false)" bit of code and
promptly used it without much thought. First timed I used the "do
loop", I admit.
They both are right.
And... one advice:
*Never ever* use exceptions to control normal program flow.
They serve to handle (as name indicates) exceptional situations while
program execution.
This is their purpose. Exception may mean from "this stupid user
entered some text again when was asked to give a numer" up to
"earthquake on the other end of the world destroyed server" ;) , but
it's always something unusual. Exception means that something has gone
wrong.
Next thing: catch exactly exception that is thrown.
If you throw ConnectException, catch this particular exception. This
way you may get some more useful info.
Also: continue (label).
In this code labels are not necessary because (as said before) they
cause jump to while statement in loop being executed. They would be
useful if you wanted to jump somewhere else. But I *strongy recommend*
*not* to do such jumps. They introduce lots of confusion and are likely
to cause a lots of bugs that will be diffult to debug because of hard
to predict program's behaviour. Whenever you want to make such jump,
think twice is there is really no other way.
Try to keep your code as short and simple as possible.
That's my advice. Take it or leave it - it's up to you.
Thea
Mike Schilling napisal(a):
> >> Does this program below indicate to you that there's a bug in java's do
> >> loop. Or is it just one of those many traps that I've fallen into and
[quoted text clipped - 59 lines]
> next thing to be done anyway, making mw wonder what the intention of the
> code is.
emrefan - 10 Aug 2006 09:12 GMT
> They both are right.
> And... one advice:
> *Never ever* use exceptions to control normal program flow.
Point taken. Didn't do that in a real program and will keep from doing
it.
> Next thing: catch exactly exception that is thrown.
What if a class of exception are to be caught and there's still a need
to be specific about a single particular one within this class? I
think I'd code thusly if the code to handle this class of exceptions
are much the same except for a tiny variation for "that special one".
> Also: continue (label).
> In this code labels are not necessary because (as said before) they
[quoted text clipped - 6 lines]
> Try to keep your code as short and simple as possible.
> That's my advice. Take it or leave it - it's up to you.
Right, avoid goto at all costs? :) Think I will still use it sparsingly
where the identation entailed by the orthodox way gets too much to be
beared.
Patricia Shanahan - 10 Aug 2006 14:43 GMT
>> They both are right.
>> And... one advice:
[quoted text clipped - 9 lines]
> think I'd code thusly if the code to handle this class of exceptions
> are much the same except for a tiny variation for "that special one".
Two points:
1. The first applicable cache block gets executed.
catch(EOFException e){
// block 1
}
catch(IOException e){
// block 2
}
runs block 1 for an EOFException, and block 2 for any IOException that
is not an EOFException.
2. If you have common code between two catch blocks you should do
exactly what you should do if you have common code between any two
related blocks in the program, see if you can make it into a method.
>> Also: continue (label).
>> In this code labels are not necessary because (as said before) they
[quoted text clipped - 10 lines]
> where the identation entailed by the orthodox way gets too much to be
> beared.
Over-deep indentation in Java is usually a sign of too much happening in
one method, and a need to refactor.
I don't believe in "avoid goto at all costs". In the decade that I spent
programming mainly in C, I did write a couple of them. However, they
were substitutes for try-finally. So far, I have not missed goto in Java.
I do generally agree with the ideas in Dijkstra's classic "Go To
Statement Considered Harmful" letter, http://www.acm.org/classics/oct95/
Patricia
Mike Schilling - 10 Aug 2006 15:19 GMT
> 1. The first applicable cache block gets executed.
"catch block", of course.
> catch(EOFException e){
> // block 1
[quoted text clipped - 5 lines]
> runs block 1 for an EOFException, and block 2 for any IOException that
> is not an EOFException.
Patricia Shanahan - 10 Aug 2006 18:03 GMT
>> 1. The first applicable cache block gets executed.
>
> "catch block", of course.
Yes, thanks for the early-morning-typo correction.
>> catch(EOFException e){
>> // block 1
[quoted text clipped - 5 lines]
>> runs block 1 for an EOFException, and block 2 for any IOException that
>> is not an EOFException.
emrefan - 10 Aug 2006 09:14 GMT
> They both are right.
> And... one advice:
> *Never ever* use exceptions to control normal program flow.
Point taken. Didn't do that in a real program and will keep from doing
it.
> Next thing: catch exactly exception that is thrown.
What if a class of exception are to be caught and there's still a need
to be specific about a single particular one within this class? I
think I'd code thusly if the code to handle this class of exceptions
are much the same except for a tiny variation for "that special one".
> Also: continue (label).
> In this code labels are not necessary because (as said before) they
[quoted text clipped - 6 lines]
> Try to keep your code as short and simple as possible.
> That's my advice. Take it or leave it - it's up to you.
Right, avoid goto at all costs? :) Think I will still use it sparsingly
where the identation entailed by the orthodox way gets too much to be
beared.