return in catch block?

[Jon Dornback]

i've recently seen several code examples that have a return statement within a catch block. am i correct in assuming that that is the return statement for the method the code is in? or does that return something from within the catch block?
corollary: can break and continue statements be used within try/catch blocks? or only for loop structures?
thanks
Jon

[Max Habibi]

Jon,
Yes, you return from a catch block. You can also return from a finally block.
No, you can't break out of a catch the way you can out of a loop. However, you _can_ throw an exception from a catch block.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Peter Phung]

The value you return doesn't need to be generated from within the method itself. The value can be declared globally and then returned from the method.

 
class1 {
public boolean doSomething() {
try {
//do something
}
catch (Exception e) {
return false;
}
return true;
}
}
class2 {
boolean var;
public boolean doSomething() {
try {
var = true;
}
catch (Exception e) {
var = false;
return var;
}
return var;
}
}
 

i hope this helps.
[ July 24, 2002: Message edited by: Peter Phung ]

[Daniela Ch]

Is it bad style is we return from inside a for loop?

[Jessica Sant]

It's VERY bad style to return in a try/catch block -- what happens in this code (from JavaOne 2002 TS-2500 Progamming Puzzlers)??

class Indecisive
{
   public static void main( String[] args )
   {
      System.out.println( waffle() );
   }
   static boolean waffle()
   {
      try
      {
         return true;
      }
      finally
      {
         return false;
      }
   }
}

So... what's the result? plop it in a file and run it.
[ December 19, 2002: Message edited by: Jessica Sant ]

[Ilja Preuss]

Originally posted by Jessica Sant:
It's VERY bad style to return in a try/catch block

I don't think this is true generally - for example, I think the following would be perfectly ok:

boolean isInteger(String string) {
  try {
    Integer.parseInt(string);
  } catch (NumberFormatException e) {
    return false;
  }
  return true;
}

[Jim Yingst]

I agree with Ilja. There are those who insist that it's bad form to have a return anywhere but the end of a method, or to use continue or break anywhere but in a switch. However in reality there are sometimes perfectly valid reasons to break these rules. Just beware that you are doing something which is at least unusual, and so it may be harder to understand for unexperienced programmers. I strongly recommend keeping each method very short (calling other methods as necessary) so that it's easy for people to see how it works. This, IMO, is far more useful than blindly obeying rules like "don't return inside a try statement".
Having said that, I will add that it's almost always a bad idea to return from inside a finally clause. That's because the return causes the JVM to forget what it was doing before it executed finally - if you were supposed to be catching an exception, that exception is now lost with no trace. Which is very, very bad. It's possible someone can think of an example where a return inside a finally is acceptable or even useful - but I doubt it.
[ December 20, 2002: Message edited by: Jim Yingst ]

[Jim Yingst]

Also, regarding the original post:
can break and continue statements be used within try/catch blocks? or only for loop structures?
Yes, it's possible to have break or continue inside a try/catch - but only if it is also inside a loop of some sort, which is either inside the try or catch, or which wraps around the try/catch. E.g.

    int num = 0;
    while (true)
    { 
      String input = JOptionPane.showInputDialog("Give me a number:");
      try
      {
        num = Integer.parseInt(input);
        break; // exits infinite while loop
      }
      catch (NumberFormatException e)
      {
        JOptionPane.showMessageDialog("I said NUMBER, you silly person.  Try again");
      }
    }

The break is associated with the loop, not the try/catch, but it's still inside a try/catch...
[ December 20, 2002: Message edited by: Jim Yingst ]

[David O'Meara]

I agree with Jessica. It's possible and people do it, but personally I hate the idea, I think it's dangerous, and it isn't that much of an effort to code around needing it.
To extend the code sample she gave, returning from a catch block doesn't necessarily cause problems, it more to do with behaviour when a finally block is there too. If you have a catch block with a return, you may not be able to safely add a finally block without rewriting the code. If the catch doesn't return, there is less chance you'll get in trouble.
If you return and re-throw exceptions in catch blocks and return from finally blocks, you can create code where it is difficult to know what is going on.
Dave

[David O'Meara]

Originally posted by Daniela Ch:
Is it bad style is we return from inside a for loop?

Returning to the original hijack and continuing from my previous post:
It is a good idea to only have a single return statement in a method that requires one. It (generally) makes the method easier to maintain.
The 'generally' refers to the counter-argument where a method that is going to fail should fail quickly.

public ReturnValue willFailQuick(Object input)
{
    if(!input instanceof Runnable)
    {
        return null;
    }
    //do the rest that actually makes sense
    ...
}

So Dave says: you can return in catch blocks and in inside 'for' loops, but if you can avoid it, don't.
Dave

[Ilja Preuss]

int foo() {
  int returnValue;
  if (booleanExpression) {
    returnValue = x;
  } else {
    returnValue = y;
  }
  return returnValue;
}

easier to maintain than

int foo() {
  if (booleanExpression) {
    return x;
  } else {
    return y;
  }
}

???
If so, why? To me, the latter seems to be much simpler...

you can return in catch blocks and in inside 'for' loops, but if you can avoid it, don't.

This seems to be a rather strange advice, as it would be *always* possible to avoid it, wouldn't it?
[ December 21, 2002: Message edited by: Ilja Preuss ]

[Jim Yingst]

Well, heck... for this particular case:

  int foo() { return booleanExpression ? x : y; }

Of course, there are those who find ternary operators upsetting and confusing as well. But at some point I think we do other programmers a disservice by coddling them too much.
I often find the "returnValue" pattern annoying anyway. It's one thing if you give the variable some other name that actually tells people what its significance is, like isValidData or hasDuplicates. That serves a useful purpose. But a name that says "this is the value I'm going to return later at the very end of the method because I'm not supposed to put a return statement here"? :roll: Just return the value and move on.
On the subject of returning withing try/catch: note that in the link Jessica gave, Joshua Bloch gives an example of returning from inside a finally, and shows why it's bad. At the end of that section, under the "Moral" section, he says: avoid abrupt completion of finally blocks. Doesn't say anything about not returning from inside a try or catch though. And in fact you can find several examples of returns from inside try or catch, in Josh's book, Effective Java. (As well as numerous examples of multiple returns.) Not that everyone has to blindly follow Josh's example of course - but since Jessica brought him up...
[ December 22, 2002: Message edited by: Jim Yingst ]

[Ilja Preuss]

OK, the example certainly was simplified to a degree that it wasn't very usefull. How about the following?

public boolean containsFittingElement() {
  for (int i = 0; i < count; i++) {
    if (fits(element[i])) {
      return true;
    }
  }
  return false;
}

vs.

public boolean containsFittingElement() {
  boolean found = false;
  for (int i = 0; i < count && !found; i++) {
    if (fits(element[i])) {
      found = true;
    }
  }
  return found;
}

[David O'Meara]

I tend to find it a bit of a catch-22 though. If a method is large and has several exits points, it is difficult to trace the flow if several other methods act the same.
The other side is that if a large method decides on the return value early on, it needs to protect that value from alteration later on

[Jim Yingst]

I'm not sure what you mean by the second point. But for the first, I agree. I think the difference is that I think all long methods are evil (well, most of them, especially if they have complicated nesting or internal returns) and you think the internal returns are evil (especially if the method is long). Not too far apart, I think.

[Ilja Preuss]

Originally posted by David O'Meara:
If a method is large and has several exits points, it is difficult to trace the flow if several other methods act the same.

Interestingly, refactoring such a method so that it only has one exit point typically only makes it even larger...
So it is my experience that it isn't multiple exit points you should avoid, but large methods!

[Dirk Schreckmann]

In case anybody else had been looking for it:
http://www.c2.com/cgi/wiki?SingleFunctionExitPoint