In Java, when should I create a checked exception, and when should it be a runtime exception? [duplicate]

by

There’s a LOT of disagreement on this topic. At my last job, we ran into some real issues with Runtime exceptions being forgotten until they showed up in production (on agedwards.com), so we resolved to use checked exceptions exclusively.

At my current job, I find that there are many who are for Runtime exceptions in many or all cases.

Here’s what I think: Using CheckedExceptions, I am forced at compile time to at least acknowledge the exception in the caller. With Runtime exceptions, I am not forced to by the compiler, but can write a unit test that makes me deal with it. Since I still believe that the earlier a bug is caught the cheaper it is to fix it, I prefer CheckedExceptions for this reason.

From a philosophical point of view, a method call is a contract to some degree between the caller and the called. Since the compiler enforces the types of parameters that are passed in, it seems symmetrical to let it enforce the types on the way out. That is, return values or exceptions.

My experience tells me that I get higher quality, that is, code that JUST WORKS, when I’m using checked exceptions. Checked exceptions may clutter code, but there are techniques to deal with this. I like to translate exceptions when passing a layer boundary. For example, if I’m passing up from my persistence layer, I would like to convert an SQL exception to a persistence exception, since the next layer up shouldn’t care that I’m persisting to a SQL database, but will want to know if something could not be persisted. Another technique I use is to create a simple hierarchy of exceptions. This lets me write cleaner code one layer up, since I can catch the superclass, and only deal with the individual subclasses when it really matters.

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. The case against checked exceptions
  5. Java List.add() UnsupportedOperationException
  6. Difference between java.lang.RuntimeException and java.lang.Exception
  7. Scanner NoSuchElementException
  8. Is it good practice to make the constructor throw an exception? [duplicate]
  9. Java: Exceptions as control flow?
  10. Throws or try-catch
  11. What is a suppressed exception?
  12. Why can’t I throw an exception in a Java 8 lambda expression? [duplicate]
  13. Mockito test a void method throws an exception
  14. Who is calling the Java Thread interrupt() method if I’m not?
  15. Update JavaFX UI from another thread
  16. How can I print error stack trace in JSP page?
  17. Exception other than RuntimeException
  18. Convert LocalDate in DD/MM/YYYY LocalDate [duplicate]
  19. java.util.ConcurrentModificationException not thrown when expected
  20. iText/BouncyCastle ClassNotFound org.bouncycastle.asn1.DEREncodable and org.bouncycastle.tsp.TimeStampTokenInfo
  21. Exception in thread “main” java.io.FileNotFoundException: Error
  22. What is the use of printStackTrace() method in Java?
  23. Why we don’t have to add try-catch to a RuntimeException?
  24. How can I catch all exceptions thrown through reading / writing a file?
  25. Print the stack trace of an exception
  26. Try-catch-finally and then again a try catch
  27. In Java, what is the difference between catch a generic exception and a specific exception (eg. IOException?)
  28. problems with java3D lib configuration
  29. Why does a Java Lambda which throws a Runtime Exception require brackets?
  30. Java 8 Supplier Exception handling with CompletableFuture

Leave a Comment