is it possible to use try catch exception inside while loop?

[exzibit23]

is it possible to use try catch exception inside while loop?

while(username_ctr <= 5){
            try{
                user1 =     str_div[username_ctr].indexOf("open_pm_tab",username_start);
                user2 = str_div[username_ctr].indexOf("')", user1);
                user3 = str_div[username_ctr].lastIndexOf(',', user2) + 3;
                str_username[username_ctr] = str_div[username_ctr].substring(user3, user2);
                //System.out.println(str_div[username_ctr].substring(user3, user2));
                username_ctr++;
            }catch(Exception e){
                slash1 = str_div[username_ctr].indexOf("</font", 0);
                slash2 = str_div[username_ctr].lastIndexOf('*', slash1);
                //System.out.println(slash1);
                //System.out.println(slash2);
                //System.out.println(str_div[username_ctr].substring(slash1, slash2));
                //System.out.println(str_div[1].substring(slash2,slash1));
                username_ctr++;
            }
        }

here's my problem.

when i got exception, it will go to catch statement, right?

but after it go to catch statement, it does not go back again to try statement even it does not get an error.

[javaAddict]

Maybe the username_ctr which you increment inside the catch becomes greater than 5.
Meaning that you need to add some debugging messages like printing the value of username_ctr.
Also I believe that you are sure that inside the catch you don't get another exception?

[JamesCherrill]

is it possible to use try catch exception inside while loop?

Yes.

You often see this in cases where you want to re-try something that may fail (throw an Exception).

[Ranvijay singh]

it's not a good idea to do some bussiness logic by using
try/catch block.as they are not made for it and if you are required to do it.then you should recheck your design.

[JamesCherrill]

it's not a good idea to do some bussiness logic by using
try/catch block.as they are not made for it and if you are required to do it.then you should recheck your design.

I've often seen this stated, but I'd be grateful if anyone could point to an authoritative source for it.

The Java API can easily put you in that situation, for example if you are using the Scanner class to parse user input then nextInt() throws InputMismatchException if the user has mis-typed. This, by design, seems to violate the "don't do business logic by Exceptions" paradigm, but it's in the API, so it should be OK.

[exzibit23]

thanks for all your reply..

i solved my problem..

[Ranvijay singh]

I've often seen this stated, but I'd be grateful if anyone could point to an authoritative source for it.

The Java API can easily put you in that situation, for example if you are using the Scanner class to parse user input then nextInt() throws InputMismatchException if the user has mis-typed. This, by design, seems to violate the "don't do business logic by Exceptions" paradigm, but it's in the API, so it should be OK.

We said that the Scanner methods that read numeric data throw a InputMismatchException exception if the next value is not int what the method expects. We can avoid that problem using Boolean methods.

if (in.hasNextInt())

    {

      number = (double)in.nextInt();

      System.out.println("You entered " + number);

    }

[GeekExplains]

it's not a good idea to do some bussiness logic by using
try/catch block.as they are not made for it and if you are required to do it.then you should recheck your design.

I guess you accidentally added 'try' (with 'catch') here as otherwise we can surely (and we do that quite often) put business logic in a try-block, can't we? Please share if you have a different view on this.

Good point that we should avoid putting in business logic in 'catch' blocks as they are probably not meant for that.

[GeekExplains]

I've often seen this stated, but I'd be grateful if anyone could point to an authoritative source for it.

The Java API can easily put you in that situation, for example if you are using the Scanner class to parse user input then nextInt() throws InputMismatchException if the user has mis-typed. This, by design, seems to violate the "don't do business logic by Exceptions" paradigm, but it's in the API, so it should be OK.

To my understanding the only authoritative source in the world of Java is the language specification (JLS), which perhaps doesn't talk about it (please point me to the section in case anyone has seen it there). And probably every other text available on this is just a suggestion/reco/best-practice-guide/etc., which different people may view differently.

Exceptions are, as we all are aware, exceptional conditions and making the business logic rely on it might give an impression that the business itself expects such conditions to occur for it to function completely. I agree that the presence of the exception-handling code do suggest the possibility of the occurrence of exceptional conditions, but does it really make sense to make part of business' functioning relying on those supposedly rare possibilities?

Exception-handlers are therefore (my views for sure) meant to identify the occurrence of those rare exceptional conditions and to do the needful mainly for: (i) handling them gracefully (ii) maintaining the business/app consistency.

I don't think the code written to perform these two steps can be thought of as a part of the 'business logic'. The second one (maintaining the consistency) might at times give that view, but that is only a support-activity to your business and not the actual business. Business is, what runs in the normal situations and everything else just lends a helping hand to make that business robust so that it can sail through in the possible abnormal conditions as well.

In your example, I see the normal condition as the one where user doesn't 'mis-type' and enters valid integers, so I would expect 'nextInt()' to give me the typed integer values in this case. Possible abnormal condition is when the user 'mis-types' and enters an invalid integer and then the exception-hanlder(s) assume their responsibility of informing the user about their mistake by throwing a relevant exception. This, kind of, maintains the robustness of the API and makes it capable of handling the possible abnormal conditions in a dignified way (instead of causing the underlying system to hang or behave in an unpredictable way).

Re-iterating that these are only my views. Happy to discuss in case you have a different viewpoint.

[~s.o.s~]

> The Java API can easily put you in that situation, for example if you
> are using the Scanner class to parse user input then nextInt()
> throws InputMismatchException if the user has mis-typed

The onus lies on the code which uses exceptions to do business processing rather than the API which throws the exception. Would the below code be wrong given that ArrayIndexOutOfBounds exception is thrown by the API:

int counter = 0;
int[] arr = new int[10];
while(true) {
  try {
    arr[counter] = counter++;
  } catch(ArrayIndexOutOfBoundsException e) {
    break;
  }
}

In the above case, the logic which relies on the exception thrown can be easily replaced by a single bounds check. Compare this to a online banking application which throws the InsufficientFundsException when a user tries to withdraw from an account having no balance. An exception throw here and caught at the UI layer seems logical since it is so much better and elegant than propagating error codes along the call hierarchy.

The case presented by you is fair enough given that it allows the API user to do processing like recording the number of times the user has failed to provide a proper answer, repeat the question or quit the application in case the user has exceeded his maximum tries. The only thing I don't agree with is considering 'accepting user input' as part of business logic; it isn't, it's a part of presentation logic.

BTW, creation of an exception is costly; if not in an absolute then at least in a relative sense since creation of stack trace is expensive [requires traversal of the call hierarchy].