Win a copy of Microservices in Action this week in the Web Services forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

Which is more efficient? (If vs try catch)  RSS feed

 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


vs

 
Matt Taylor
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry I can't see the edit function on my thread, here's the comparison:




vs


 
Ranch Hand
Posts: 614
9
BSD Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Rancher
Posts: 3763
40
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 19995
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 23881
50
Eclipse IDE Firefox Browser MySQL Database
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Matt Taylor wrote:



I would rewrite that as



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.

 
Marshal
Posts: 67164
169
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The answer to 99% off questions that begin "Which is more efficient...?" is "It doesn't matter. Use whatever provides the best clarity."
 
Sheriff
Posts: 21466
97
Chrome Eclipse IDE Java Spring Ubuntu VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

So not only is an if statement clearer, it's also faster.
 
Marshal
Posts: 61787
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.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.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!