9

How much better is:

 if (condition) {
  try {
   //something
  } catch(SomeEx ex) {}
 }

instead of this:

 try {
   if (condition) {
     //something
   }
 } catch(SomeEx ex) {}

What actually JVM do when I enter try block ?

EDIT: I don't want to know that in second example always go in to try... Please answer the question.

Smolda
  • 882
  • 5
  • 13
  • 34
  • 1
    It depends on your usage and actual scenario. – Nandkumar Tekale Jul 31 '13 at 09:19
  • @Nandkumar Tekale: Not it's not.. It is always the same. Since we have the same JAVA. – Smolda Jul 31 '13 at 09:26
  • Possible duplicate of [Is it expensive to use try-catch blocks even if an exception is never thrown?](http://stackoverflow.com/questions/16451777/is-it-expensive-to-use-try-catch-blocks-even-if-an-exception-is-never-thrown) – e4c5 Oct 20 '15 at 11:53

6 Answers6

11

Execution wise at run time, as long as there is no exception, try does not cost you anything. It only costs run time as soon as an exception occurs. And in that situation it is much slower that an if evaluation.

In the JVM spec, you see that there is no extra byte code generated on the execution path: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-3.html#jvms-3.12

FrankPl
  • 13,205
  • 2
  • 14
  • 40
  • 1
    T0 aload_0 // Begin try block – Smolda Jul 31 '13 at 09:28
  • 1
    @Smolda - I do not understand your comment. Do you want to say that the `aload_0` in the sample code of the spec is for the try? That is not true. It is the loading of the `this` reference for the method call in the next line. And that is needed no matter if you use try or not. The comment in the sample code is a bit misleading. – FrankPl Jul 31 '13 at 09:48
  • This answer doesn't really explain anything and is unlikely to be correct. As exceptions are mostly a feature of the runtime (the JVM) and not of bytecodes, bytecodes are irrelevant. If you want to evaluate real cost, you would have to look at what the JVM does when it enters a try-block (or what assembler it generates for code that's JIT compiled). In any case it is certainly not free. – jrudolph Oct 08 '15 at 13:26
  • Seems I was somewhat wrong about the cost. It could be free (i.e. equally expensive in the OP's example) but not for the reasons stated here. See http://stackoverflow.com/a/16451908/7647 – jrudolph Oct 08 '15 at 13:38
3
try {if (condition) {...}} catch(SomeEx ex) {}

Here you handled the exception if it is arised condition of if also if arised inside if-block.

if (condition) {try {...} catch(SomeEx ex) {}}

Here you handle exception if is arised only inside the if-block. If something goes wrong in if condition then it will not be handled.

So it is depends upon the actual senario.

Subhrajyoti Majumder
  • 40,646
  • 13
  • 77
  • 103
1

From the perfomance point of view it should be the same. Throwing of the exception is a costly operation (for starters, the stacktrace must be created and populated). The mere existence of the try block has no (or negligible) performance penalty.

See Should java try blocks be scoped as tightly as possible.

What actually JVM do when I enter try block ?

From JLS 14.20.1. Execution of try-catch:

A try statement without a finally block is executed by first executing the try block. Then there is a choice:

  • If execution of the try block completes normally, then no further action is taken and the try statement completes normally.

  • If execution of the try block completes abruptly because of a throw of a value V, then there is a choice:

    • If the run-time type of V is assignment compatible with (§5.2) a catchable exception class of any catch clause of the try statement, then the first (leftmost) such catch clause is selected. The value V is assigned to the parameter of the selected catch clause, and the Block of that catch clause is executed, and then there is a choice:

      • If that block completes normally, then the try statement completes normally.

      • If that block completes abruptly for any reason, then the try statement completes abruptly for the same reason.

    • If the run-time type of V is not assignment compatible with a catchable exception class of any catch clause of the try statement, then the try statement completes abruptly because of a throw of the value V.

  • If execution of the try block completes abruptly for any other reason, then the try statement completes abruptly for the same reason.

EDIT:

For a complete Exception description see the JVM 2.10 link in The New Idiot's answer.

Community
  • 1
  • 1
linski
  • 5,046
  • 3
  • 22
  • 35
0
if (condition) {
  try {
   //something
  } catch(SomeEx ex) {}
 }

is better to use since it executes the try block if the condition is ok.JVM compiles the try block and validated the catch block or a finally block. I think advantage is not in the compile time but in the run time. Compile time I think no advantage at all

Sanjaya Liyanage
  • 4,706
  • 9
  • 36
  • 50
  • That is what I said.. can you please answer the question ? – Smolda Jul 31 '13 at 09:19
  • JVM compiles the try block and validated the catch block or a finally block. I think advantage is not in the compile time but in the run time. Compile time I think no advantage at all – Sanjaya Liyanage Jul 31 '13 at 09:22
0

Exceptions should be exceptional case , not every time the code runs. So better to check for the condition before trying !

if (condition) {
  try {
    //something
  } catch(SomeEx ex) {}
}

Make sure , if (condition) itself doesn't throws an Exception.

It depends on your usage and functionality . For example this would be better :

if (someObject!=null) {
  try {
     someObject.getSomething(); // getSomething() potentially throws some Exception
  } catch(SomeEx ex) {}
}

What actually JVM do when I enter try block ?

Read JVM spec 2.10.

AllTooSir
  • 48,828
  • 16
  • 130
  • 164
  • This is nonsense. If the condition is unlikely the overhead of testing as well as catching is unwarranted, and the suggestion also introduces (a) a timing window problem (b) the problem of testing exactly the same condition twice and (c) the issue of having to write the same error handling code twice. -1 – user207421 Jul 31 '13 at 09:50
  • 2
    @EJP (1)I disagree with you , it is better to avoid a certain NPE than to ask the try to throw it later . (2) it is not testing the same condition twice , please read the comment in the code (3) I would better have my catch block to catch potential checked Exceptions rather than runtime exceptions ! – AllTooSir Jul 31 '13 at 10:00
0

If you see oracle docs

>try {
    code
}
catch and finally blocks . . .

The segment in the example labeled code contains one or more legal lines of code that could throw an exception.

So,If you feel doubt on your If condition that it will throw an exception put it inside.Otherwise put outside.

Suresh Atta
  • 120,458
  • 37
  • 198
  • 307