Checked vs Unchecked Exceptions in Java

by

CheckedException needs to be handled by the caller, Unchecked exception don’t.

So, when you design your application you should take in mind what kind of exceptional situation you are managing.

For example, if you design a validation method that checks the validity of some user input, then you know that the caller must check the validation exception and display the errors to the user in a nice looking way. This should be a checked exception.

Or, for those exceptional conditions that can be recovered: imagine you have a load balancer and you want notify the caller that one of the “n” servers is down, so the caller must recover the incident re-routing the message to another server; this should be a checked exception, because it is crucial that the caller (client) tries to recover the error, and don’t just let the error to break the program flow.

Instead, there are many conditions that should not happen, and/or should instead break the program. For example, a programming error (like division by zero, null pointer exception), a wrong usage of an API (IllegalStateException, OperationNotSupportedException), an hardware crash, or just some minor situation that are not recoverable (lost connection to a server), or a doomsday 🙂 ; in those cases, the normal handling is to let the exception reach the most outer block of your code that displays to the user that an unpredictable error has occurred and the application can’t do nothing to continue. It’s a a fatal condition, so the only thing you can do is to print it to the logs or showing it to the user in the user interface. In those cases, catching the exception is wrong, because, after catching the exception you need to manually stop the program to avoid further damages; so it could be better to let some kind of exception “hit the fan” 🙂

For those reasons there are some exceptions that are Unchecked also in the JRE: OutOfMemoryError (unrecoverable), NullPointerException (it’s a bug that needs to be fixed), ArrayIndexOutOfBoundsException (another bug example), and so on.

I personally think that also SQLException should be unchecked, since it denotes a bug in the program, or a connection problem to the database. But there are many examples where you get exception that you really don’t have any clue in how to manage (RemoteException).

The best way to handle exceptions are: if you can recover or manage the exception, handle it. Otherwise let the exception pass out; somebody else will need to handle. If you are the last “somebody else” and you don’t know how to handle an exception, just display it (log or display in the UI).

More Related Contents:

  1. NumberFormatException not wrking java
  2. How to create exception from another class
  3. Understanding checked vs unchecked exceptions in Java
  4. IllegalArgumentException or NullPointerException for a null parameter? [closed]
  5. The case against checked exceptions
  6. Java List.add() UnsupportedOperationException
  7. Scanner NoSuchElementException
  8. How do you implement a re-try-catch?
  9. Should you report the message text of exceptions?
  10. Exception thrown inside catch block – will it be caught again?
  11. How to catch a Firebase Auth specific exceptions
  12. Java: Global Exception Handler
  13. Throws or try-catch
  14. Why can’t I throw an exception in a Java 8 lambda expression? [duplicate]
  15. What are reasons for Exceptions not to be compatible with throws clauses?
  16. Mockito test a void method throws an exception
  17. Who is calling the Java Thread interrupt() method if I’m not?
  18. Update JavaFX UI from another thread
  19. How can I print error stack trace in JSP page?
  20. Convert LocalDate in DD/MM/YYYY LocalDate [duplicate]
  21. java.util.ConcurrentModificationException not thrown when expected
  22. iText/BouncyCastle ClassNotFound org.bouncycastle.asn1.DEREncodable and org.bouncycastle.tsp.TimeStampTokenInfo
  23. Getting Exception org.apache.logging.slf4j.SLF4JLoggerContext cannot be cast to org.apache.logging.log4j.core.LoggerContext
  24. What is the use of printStackTrace() method in Java?
  25. Why we don’t have to add try-catch to a RuntimeException?
  26. Is it a bad idea to use printStackTrace() for caugt Exceptions?
  27. Is there an unhandled exception handler in Java?
  28. The local variable might not have been initialized – Detect unchecked exception throw within a method
  29. org.openqa.selenium.UnhandledAlertException: unexpected alert open
  30. Side effects of throwing an exception inside a synchronized clause?

Leave a Comment