Any easy way to get out of a Java block?

Question

I was just wondering if there is any way to get out of a Java block. It can be any block - if block, for block or even a simple {}. This is because I often come across such situations

{
  retCode = performSomeThing();
  if(retCode == SUCCESS)
  {
    retCode = performSomethingElse();
    if(retCode == SUCCESS)
    {
         . . . 
          . . . 
    }
   }
}

This multiple levels of indentation clutters up the code I write.

Instead I need some way to do this

if((retCode = performSomething()) != SUCCESS)
  GET_OUT_OF_BLOCK
if((retCode = performSomethingElse()) != SUCCESS)
  GET_OUT_OF_BLOCK

Based on the value of retCode I will perform any required processing outside the block. Would be nice if it doesn't involve writing that block within a try-catch block, creating a new exception type, throwing it and then catching it.

There actually is goto in Java. If I catch you using it I'll lob off your ears. — defines, Jul 01 '10 at 11:28
@Dustin: It's impossible to use goto in Java - it's a reserved word (i.e. not a legal identifier), but not actually used for anything. — Michael Borgwardt, Jul 01 '10 at 11:38
Impossible is nothing. Hard core programmers code byte code directly and frequently use the goto opcode.. — emory, Jul 01 '10 at 12:07
@emory, that makes [this](http://stackoverflow.com/questions/3150254/programming-in-java-bytecode) a related question. — Pops, Jul 01 '10 at 14:37
In retrospect, I was thinking from a "each method should have only one return" school of thought, which was a pretty stupid way of thinking. — Jagat, May 07 '14 at 06:26

score 20 · Accepted Answer · answered Jul 01 '10 at 10:27

The correct construct to use is return. This implies that what is a block in your example should really be a method, but that is a good idea anyway - methods that are so long that they contain multiple, complicated control flow alternatives are an antipattern. Do yourself a favor and switch to "one objective per method" today! <end of evangelism>

score 7 · Answer 2 · answered Jul 01 '10 at 11:25

7

have a look at break and continue

answered Jul 01 '10 at 11:25

Thorbjørn Ravn Andersen

73,784
33
194
347

The only other correct answer, how is this not getting voted up? – defines Jul 01 '10 at 11:26

score 2 · Answer 3 · answered Jul 01 '10 at 10:31

2

You seem to use the nested ifs here for error handling.

If you switch to structured exception handling, maybe you could get rid of the deeply nested if constructs at all.

This would, however, imply that performSomeThing() and performSomethingElse() would throw exceptions instead of returning error codes.

answered Jul 01 '10 at 10:31

Frank

2,628
15
14

2

Using exceptions for non-exceptional conditions or control flow is definitely not recommended. – eljenso Jul 01 '10 at 11:19
@eljenso: Well, if you need to abort processing because an operation was not successful, that would be a good case for using an exception. But it's always a bit of a judgment call... – sleske Jul 01 '10 at 11:21
Exceptions are for crash-and-burn situations. If you now beforehand that some operation may fail (for example due to certain values in your data) and you know you have to deal with it (validation) then using an exception is the wrong choice. So probably the best solution here would be return codes (as the OP did) + unchecked exceptions. – eljenso Jul 01 '10 at 11:28
2

@eljenso: Exceptions are perfectly fine for validation errors when it makes sense to have them propagate up the call stack. The decision between exceptions and return codes should not be based on hair-splitting about what exactly is an "exceptional situation", but about what leads to better design. Error codes that must not be ignored and have to be passed around are bad, no matter what causes them. – Michael Borgwardt Jul 01 '10 at 11:43
@Michael It is indeed about better design. Using exceptions for "normal" control-flow, for things your program is expected to handle, is often not the best choice. Hair-splitting is not involved because you know what your program is supposed to do, right? – eljenso Jul 01 '10 at 12:03
@eljenso: following that logic, exceptions should never be used for anything that doesn't cause the program to abort (i.e. they basically should never be caught). Arguing about what is or is not "normal control-flow" invariably ends up in hair-splitting about edge cases. IMO the name "exception" is a red herring. They're simply another flow control construct, one that allows passing control up the call stack. They're better than return codes for things that don't concern the immediate calling method, not so good for things that method will handle, and horrible for method-internal flow control – Michael Borgwardt Jul 01 '10 at 12:15
@Michael Ok, good points. Still, I prefer to warn people against using exceptions as described above because it can get real messy. Exceptions bubbling up the stack waiting to be caught also tend to break encapsulation and increase coupling. Also, as you point out, I *do* think that exceptions should rarely be caught (or, put otherwise, you should have relatively few try/catch constructs) unless (a) you're forced by API (b) top-level "catch-all". But as with all advice/rules/guidelines: you can decide to go against it. – eljenso Jul 01 '10 at 13:35

score -1 · Answer 4 · answered Jul 01 '10 at 11:30

Don't do that. In my opinion the correct way for a bloc is one start at the beginning, one stop at the end, full stop.

Even with a method, you should have only one return at the end.

Inside the bloc, you write the flow of the running instructions with if and so on, from the start to the end, the more simple you can (so, sometimes, you write return or break etc inside it, ok ; it should be exception).

It's best (but not mandatory) to write normal completion statements.

-1 for providing a personal opinion rather than a technically correct answer — Pops, Jul 01 '10 at 14:39

Any easy way to get out of a Java block?

4 Answers4