What is the cost of try catch blocks?

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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 .

Answer 4

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

Answer 5

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

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 .

Answer 6

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.