Which is more efficient? (If vs try catch)

[Matt Taylor]

String storage = null;

if (!checkForStringValue.isEmpty()){
storage = checkForStringValue.trim();
}

vs

String storage = null;

try{
storage = checkForStringValue.trim();
}catch(Exception e){
}

[Matt Taylor]

Sorry I can't see the edit function on my thread, here's the comparison:

String storage = null;
 
if (checkForStringValue != null && !checkForStringValue.isEmpty()){
storage = checkForStringValue.trim();
}

vs

String storage = null;
 
try{
storage = checkForStringValue.trim();
}catch(Exception e){
}

[Tapas Chand]

IMO if condition is better to use.
It is not about efficiency but about usage.
If you use if-condition you can do things after that in case String is null.
But if you use try-catch flow will jump to catch in case String is null without executing other statements.

Multiple try blocks can be used to execute further statements in case of Exception, but I usually avoid them.

[Dave Tolls]

In my opinion NullPointerException should be considered to be an error in your code, so catching one should be viewed as a sticking plaster over a bug.
So for me the 'if' is the proper way of handling this.

[Tim Holloway]

Historically, exceptions have carried significantly more overhead than simple conditions. However, it's always best to actually measure the specific conditions rather than optimize based on what you "know".

Having said that, exceptions have very different characteristics than conditionals.

Conditionals are local in scope. Everything is right in the same block of code in the same method. Exceptions transcend scope. Once you throw an Exception, it will percolate up until something catches it.

Exceptions allow attaching an arbitrary payload. Unlike a return statement (conditional or not), you can return other sorts of data from a method than what the method was declared to return. For example, consider an XML parser method. Normally it might return a DOM tree, but an Exception might return a class object containing the name and line number of a point in an input file where there was a syntactical or semantic problem.

I strongly discourage the free use of NullPointerException. A number of popular libraries use the NPE and it's a serious problem for me. In my code, an NPE is likely going to come from a bug in the code and if I set up my debugger to grab control every time a NullPointerException is thrown it really slows down the process. It's far better to use a more specific Exception. Better still, define Exception classes specific to your app.

[Paul Clapham]

Matt Taylor wrote:

if (!checkForStringValue.isEmpty()){
storage = checkForStringValue.trim();
}

I would rewrite that as

storage = checkForStringValue.trim();

In my opinion spending any time at all to determine whether it takes longer to trim an empty string than to determine whether a string is empty is almost pointless. (For all I know the actual implementation of the trim() method does the zero-length test interally anyway.) The exception would be if your code spent the majority of its time trimming blank space off the ends of String values. Which it almost certainly doesn't.

[Bear Bibeault]

The answer to 99% off questions that begin "Which is more efficient...?" is "It doesn't matter. Use whatever provides the best clarity."

[Rob Spoor]

But in this case it does matter. I've written a utility method that retrieves a named value of an enum, and returns null if it doesn't exist (instead of throwing an IllegalArgumentException). A literal quote from that code:

// using Enum.valueOf(cls, name) is faster if the name is valid, but horribly slower if not

So not only is an if statement clearer, it's also faster.

[Campbell Ritchie]

Tim Holloway wrote:. . . However, it's always best to actually measure the specific conditions rather than optimize based on what you "know". . . .

The copy of Core JavaII by Cay Horstmann, which I had the good fortune to win in the JiG forum back in the Spring says they tested ifs vs Exceptions and found the exceptions were about 50× slower. But never mind the width, feel the quality. Sorry. Never mind the speed, feel the elegance. A throw and a catch in the same method look inelegant, and they are not really what an exception is for. At least that is what I think.
The idea of an exception is for method A to tell method B that it didn't work. Then method B can consider whether to take action (catch) or let another method take action (let the exception propagate). The bit of code shown seems specially designed to be confusing and to produce NPEs.

String text = null;
// ...
if (text != null && !text.isEmpty())
{
   text = text.trim();
}

No need for a try there.

But what is wrong with NPEs? If you get a null which you don't want, throw NPEs. The bigger they are and the harder you throw them, the better. And throw them as soon as the null makes its presence felt. Don't wait until it can do harm elsewhere. Splat the blighter! The wrong thing to do with NPEs is to catch them. They shou‍ld be allowed to propagate until your users learn to avoid nulls. And setting a local variable to an initial value of null; well at least it is only in a forum post and not in real‑life code.

MT: if you are going to catch exceptions, avoid catch (Exception exc), even if you see it in books. Use the most specific type of Exception you can force into your code. Use multiple catch blocks if the different sorts of Exception require different actions. Read more about Exceptions in the Java™ Tutorials.