1

i thought about the fact, that using try and catch is useful to prevent crashes if there are mistakes, but i was curious if there is any impact at the performance if i overuse the try and catch block.

To resume: Is there any impact at the performance if i use try and catch(nearly) everywhere?

Improve this question
6
  • 3
    Performance, probably not. Sanity, probably yes. If a runtime exception happens in your program, one of the best things you can do is crash with as useful an error message as possible. Commented Dec 21, 2016 at 21:40
  • 1
    If you're using it enough to provoke a performance issue, then your code smells... Hint: safaribooksonline.com/library/view/effective-java-2nd/… Commented Dec 21, 2016 at 21:41
  • 1
    The main problems with over use of exceptions are not the performance ones, but the code legibility ones. If you are doing something where failure is a common and expected occurrence, you shouldn't hide the main logic flow in an exception handling chain. Exceptions are, after all, for exceptional events, not for expected ones. Commented Dec 21, 2016 at 22:00
  • 2
    The answers pointed out that overusing exceptions has other issues. However, focussing at the point: try...catch will basically have no influence on the performance. But throwing exceptions may have. And it may be severe. Creating the stack trace can really be costly. Read more about this at shipilev.net/blog/2014/exceptional-performance Commented Dec 21, 2016 at 23:24
  • 1
    "i thought about the fact, that using try and catch is useful to prevent crashes" - no, it's not... except for a few places. You only ever should catch an exception, if you either have to (e.g., IOException in Runnable#run) or you can do something really meaningful about it. Other uses just obfuscate the code. Commented Dec 22, 2016 at 2:29

2 Answers 2

Reset to default
2

Exception throwing/handling does come with a slight performance penalty (the exact amount varies greatly by the exact scenario), but performance shouldn't be your first consideration.

  1. Correctness: First of all, make sure that your code does what it needs to do. Don't treat normal use cases as exceptional, for example if a user types in an incorrect value in a field, that's nothing special, no need to throw exceptions for that. But if something is genuinely exceptional (like you can't connect to the database), and you can't deal with it at the point it occurs, throw an exception. And if the exception comes from "below", from a JDK class or a third party library, you have no other option than to handle it.
  2. Readability. Constantly catching and re-throwing exceptions can make your code near impossible to follow, debug or maintain. The same goes for swallowing exceptions without a trace. What you should aim for instead is a consistent strategy for handling exceptions. Basically you should only handle exceptions on the level where you can do something about them.
  3. Performance. This should be your last port of call, once you get the first two sorted. It is unlikely that you'll ever be in a place where your code is correct and readable, and still exception handling is the main bottleneck of your application, but if you do get there, you can try returning error codes rather than throwing exceptions, or completely restructuring your code to avoid them.
Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

2

I think the main hit to performance you are going to see (assuming the code in question is executed at a very high frequency) will be from garbage collection.

One trivial example (this you do actually see in production code every now and then ...) would be having password verification logic like:

if (!password.equals(correctPassword)) { throw new IncorrectPasswordException(); }

and then ...

catch (final IncorrectPasswordException ex) { //some output or so }

... instead of simply never throwing anything and just handling this via conditionals. You will eventually have to clean up all those IncorrectPasswordException from memory.

In this case overusing exceptions actually will become pretty costly by turning simple evaluations into object instantiations that cost you memory and even more importantly eventually cost you precious CPU cycles for reclaiming that memory via garbage collection.

Improve this answer

1 Comment

To be fair, almost any large Java application is creating objects at a huge rate and throwing an exception as part of "normal" control flow isn't going to be a major source of garbage, unless it's in the middle of some tight loop. Certainly throwing for incorrect passwords would be fine in any reasonable application.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.