2

We all know try-catch blocks inhibit certain compiler optimizations, as stated in the following:

"Placing code inside try-catch block inhibits certain optimizations that JVM implementations otherwise perform." Effective Java, Item 69 (Joshua Bloch)

Is it expensive to use try-catch blocks even if an exception is never thrown?

So, what about web applications? In web application, specifically in controllers, everything is - at some level - contained in a try-catch block. We know that because, in case of an unhandled exception, our app won't crash but returns a Server Error 500. Can we say that any code running within a web controller is implicitly checked for exceptions, with the consequences that we mentioned (inhibited optimization)?

UPDATE. I try to narrow down the question, which is purely theoretical by the way. The original assumption is: JVMs cannot apply certain optimizations to code inside a try-catch block. So:

Does the lack of those optimizations apply also to method calls?

Or in other words:

Can JVMs optimize code inside a method called from a try-catch block? Or does a try-catch block prevent optimization on any piece of code - even method calls down the stacktrace - executed within it?

Sam
  • 899
  • 6
  • 9

2 Answers2

0

The answer is basically: Yes, those optimisations are impossible for those calls, but no, it doesn't matter.

There are very few web requests per second. Spending even 1000% longer on the call than for a call without a catch block doesn't matter, because that try/catch block is executed at most a few thousand times per second. Try/catch only slows down the call, not calls inside the call, see?

arnt
  • 8,949
  • 5
  • 24
  • 32
  • Sorry, that is not very clear. – Sam Jun 30 '18 at 12:54
  • I'm not concern if it matters or not, the question is purely theoretical: it is about how JVMs work. So, even though you answered, I would expect you to elaborate some arguments. Thanks – Sam Jun 30 '18 at 12:59
  • Try/catch in YourRequestHandler.foo() changes the performance if your foo(). It does not change the performance if e.g. String.toUpperCase(). This is easily verified by measurement. Now, toUpperCase() may be called any number of times, perhaps few, perhaps many, but your request handler is called *precisely* as many times as there are HTTP requests. Which, in CPU terms, is approximately zero. The functions that are hotspot in a typical program are called *vastly* more than x00 times per second, and x00 requests per cpusecond is a decent speed for many APIs. – arnt Jul 01 '18 at 15:12
-1

I would expect web server to always return some answer, either 200 or 500 in case of error. In java you have generally two possibilities to signal error, either throwing exception or returning error response code (-flag) (like in languages without exceptions, e.g. C). In this article is nice comparison of those two approaches (paragraph Lil' Exception Meets The Obnoxious Flags) https://shipilev.net/blog/2014/exceptional-performance/ where is stated

exception actually works better than flags for up to roughly 10-3 frequency in the default mode. The reason is that the non-exceptional path enjoys no additional overheads of checking the exceptions, since the exception handling code is laid out and handled elsewhere. Of course as exceptions are getting more frequent, we pay for both stack traces, and VM handling of the exceptions.

So I would assume, even if they were inhibiting some JVM optimizations, this way to handle errors is still preferable.

Michal
  • 970
  • 7
  • 11