0

Are there scenarios where you could argue that when an exception is created that both a checked exception and an unchecked exception can be used? Then the speed and performance can be measured against each other

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
ChrisLifts
  • 3
  • 1
  • 1
    You can always use (un)checked exceptions if you create your own exceptions. The only difference is whether or not you have to define that your method throws the specific exception. [But this should never be the sole reason why you use an unchecked instead of an checked exception](https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html). – Turing85 Oct 30 '17 at 14:10
  • 1
    Checked exceptions are actually only enforced at compile time. Whether an exception is checked or unchecked has no impact whatsoever on performance. (But they do make a difference in clarity of design.) – VGR Oct 30 '17 at 14:18
  • This is a matter of opinion and debate. From the performance point of view, there's no difference: throwing an exception is always very expensive. But, as exceptions occur *exceptionally*, this is OK. Whether you use either checked or unchecked exceptions, is then a matter of design. And you have the school that says that you must use checked exceptions because they force you and whoever uses your code to stick to the contract of your method, while the other school says that if you use checked exceptions you end up polluting your code with a lot of useless try/catch blocks... – fps Oct 30 '17 at 14:44
  • 1
    I personally hate checked exceptions because I think that code readability and clarity should be the most important, and that you shouldn't write too much code to handle exceptional situations, but common ones instead. But it's just my point of view on this topic, and other points of view are equally valid as well. – fps Oct 30 '17 at 14:46

3 Answers3

1

From the perfomance point of view, building stack trace for exception is anyway the longest operation when an exception is generated (details).

Checked and unchecked exceptions make difference only at compile time. The Java compiler forces you to either catch checked exceptions or declare them in the method signature. It was supposed to improve program safety, but the majority opinion seems to be that it's not worth the design problems it creates.

There is even Lomboks "magical" @SneakyThrows annotation to overcome this compile-time check. On the JVM (class file) level, all exceptions, checked or not, can be thrown regardless of the throws clause of your methods, which is why this works.

Dmitriusan
  • 11,525
  • 3
  • 38
  • 38
0

As the others already said, there is no performance difference between checked and unchecked exceptions.

But if you think that the performance of throwing or handling exceptions might be important for your application, you're doing something terribly wrong.

Exceptions are meant to tell your caller that your method could not fulfill its task. If this happens so often that it affects your program's overall performance, you have a bigger problem than just the performance - you have a non-functional program!

Always throw exceptions when you find a method can't fulfill its task, and catch exceptions only in places where you can reasonably continue even after some unspecified failure of some method nested deeply in your call stack (that's what the exception tells you) - typically, that's some top level (like e.g. the menu bar action of a desktop app). To save you from writing lots of throws clases, unchecked exceptions can be helpful - but that's opinion-based.

Ralf Kleberhoff
  • 6,990
  • 1
  • 13
  • 7
0

Throwing an exception is very expensive because you need to calculate all of your stack traces, because of it often helps with performance just return null/-1/etc. Or you could use the constructor of Exception without writableStackTrace. it's the last parameters in the constructor. https://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html

protected Exception(String message, Throwable cause, boolean enableSuppression, boolean writableStackTrace)

Aleksandr Lovkov
  • 65
  • 9