Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / August 2006

Tip: Looking for answers? Try searching our database.

do loop bug?

Thread view: 
emrefan - 10 Aug 2006 02:22 GMT
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
I've only got myself to blame? I was expecting the two loops would
behave much the same. Have I been bitten by the optimizer?

public class DoLoopBug {
  public static void main( String[] args ) {
     int retryCnt = 0;
     doLoop1: do {
        try {
           if (retryCnt < 3)
              throw new java.net.ConnectException();
           break;
        }
        catch (Exception e) {
           System.out.println( "caught exception; retryCnt=" +
retryCnt );
           if (++retryCnt < 20)
              continue doLoop1;
        }
     } while (false);

     System.out.println( "after doLoop1, retryCnt = " + retryCnt +
"\n" );

     retryCnt = 0;

     doLoop2: do {
        try {
           if (retryCnt < 3)
              throw new java.net.ConnectException();
           break;
        }
        catch (Exception e) {
           System.out.println( "caught exception; retryCnt=" +
retryCnt );
           if (++retryCnt < 20)
              continue doLoop2;
        }
     } while (true);  // Here's difference from DoLoop1

     System.out.println( "after doLoop2, retryCnt = " + retryCnt );
  }
}
Patricia Shanahan - 10 Aug 2006 02:37 GMT
> 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 - 40 lines]
>    }
> }

The results I get are:

caught exception; retryCnt=0
after doLoop1, retryCnt = 1

caught exception; retryCnt=0
caught exception; retryCnt=1
caught exception; retryCnt=2
after doLoop2, retryCnt = 3

which is what I expected.

Each continue effectively jumps to its loop's while expression
evaluation. For the first loop, the expression evaluates to false, so it
falls through first time.

For the second loop, the while expression evaluates to true, so it does
another iteration. That goes on until retryCnt reaches 3, and the break
is executed instead of the throw leading to a continue.

If this does not answer your question, perhaps you could explain why you
expected the two loops to behave the same?

Patricia
Mike Schilling - 10 Aug 2006 06:32 GMT
>> 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 - 55 lines]
> 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.
Patricia Shanahan - 10 Aug 2006 07:36 GMT
...
>> 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.
Thea - 10 Aug 2006 07:53 GMT
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.
emrefan - 10 Aug 2006 08:50 GMT
> The results I get are:
>
[quoted text clipped - 11 lines]
> evaluation. For the first loop, the expression evaluates to false, so it
> falls through first time.

Thank you for responding.

This surprises me! I was expecting the continue to restart the loop
without even looking at the while expression.  I need to brush up on
java basics <blush>. Maybe other languages have poisoned me.

> For the second loop, the while expression evaluates to true, so it does
> another iteration. That goes on until retryCnt reaches 3, and the break
> is executed instead of the throw leading to a continue.
>
> If this does not answer your question, perhaps you could explain why you
> expected the two loops to behave the same?

Well, I used such a strange construct in the real thing because I
wanted to retry some servlet accessing operation if a
java.net.ConnectException happened. And indeed this exception happened
quite often for a particular customer who was running the relevant
applet. It did not happen each and every time for this customer and
other customers were not suffering the same problem - at least not
frequently enough for them to raise an issue with us.

You explanation is perfectly clear to me. But the "continue to the
while expression" bit trapped me up.
Mike Schilling - 10 Aug 2006 09:12 GMT
> Well, I used such a strange construct in the real thing because I
> wanted to retry some servlet accessing operation if a
[quoted text clipped - 6 lines]
> You explanation is perfectly clear to me. But the "continue to the
> while expression" bit trapped me up.

If you're loooking for a construct that says "retry if an exception
happened", here's a thought:

   boolean done = false;
   while (!done)
   {
       try
       {
           ...
          done = true;
       }
       catch (Exception ex)
       {
           ...
       }
   }

This will exit the loop only if the code in the try block throws no
exceptions. Of course, you can tinker with it to limit the number of
retries, say

   boolean done = false;
   int retryCount = 0;
   while (!done && retryCount < 3)
   {
       try
       {
           ...
          done = true;
       }
       catch (Exception ex)
       {
           ...
           retryCount++;
       }
   }


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.