{"id":83,"date":"2021-01-17T23:11:00","date_gmt":"2021-01-17T21:11:00","guid":{"rendered":"http:\/\/victorrentea.ro\/blog\/?p=83"},"modified":"2021-01-29T01:18:58","modified_gmt":"2021-01-28T23:18:58","slug":"exception-handling-guide-in-java","status":"publish","type":"post","link":"https:\/\/victorrentea.ro\/blog\/exception-handling-guide-in-java\/","title":{"rendered":"Exception Handling Guide in Java"},"content":{"rendered":"
<\/div>\n

This article presents a pragmatic, clean approach to working with exceptions in the Java applications we build today.<\/p>\n\n\n\n

If you want a live walk through the concepts in this article and the others related to exception handling, here is a talk I gave on this topic at the Java Champions Conference in 2021:<\/p>\n\n\n\n

https:\/\/www.youtube.com\/watch?v=LRwCE7GreSM<\/a><\/p>\n\n\n

A Bit of History<\/h2>\n

At first, there were no exceptions.<\/p>\n

Forty years ago, when a C function wanted to signal an abnormal termination, it would return a -1<\/code> or NULL<\/code>. But if the caller forgot to check the returned value, the error would go unnoticed.<\/p>\n

In 1985, C++ tried to fix that by introducing exceptions that propagate down the call stack and, unless caught, terminate the program execution. However, developers suddenly were facing a new challenge: how would the caller know what exceptions are thrown by the function they called?<\/p>\n

Ten years later, Java was born. Since all developers back then were using C\/C++, one goal of Java was to attract them with features like Garbage Collection, safe references (instead of pointers), smooth build process, unified source code (instead of .h\/.cpp), portability, and others. At the same time, Gosling, the father of Java, tried to fix the problem of mysterious exceptions by forcing developers to become aware of checked exceptions<\/strong> thrown by the functions they called. Of course, some errors couldn\u2019t be foreseen (like ArrayOutOfBoundsException<\/code> or NullPointerException<\/code>), so these remained invisible runtime exceptions<\/strong>.<\/p>\n

You probably already know that checked exceptions should be used only for “recoverable errors”. Only then it pays to force your caller to try-catch<\/code> or throws<\/code> your exception.<\/p>\n

But all this was happening in The Age of Libraries<\/em>. In the \u201890s, developers realized the importance of reuse: libraries and frameworks were being created everywhere. The truth is that when writing a library, it\u2019s very tempting to consider that the code using it might be able to recover from a wide range of errors, especially if you don\u2019t have a very clear picture of how your clients will use it. Thus, the urge towards checked exceptions: let\u2019s notify our callers of everything,… as they might be able to recover.<\/p>\n

Furthermore, back in those days, many applications implemented UI or batches, and these typically need to handle the exceptions to prevent them from terminating the program.<\/p>\n

But that age is gone.<\/p>\n

In the applications we write today, we rarely recover from exceptions. Instead, we terminate the execution of the current use-case ASAP. In a web application, we would return a 400\/500 HTTP status code. When handling messages from queues, we might reject that message. And in a batch, we would probably skip or report that line with (eg) Spring Batch\u2019s assistance. We rarely recover from an error anymore.<\/p>\n

\"file\"<\/p>\n

Disclaimer<\/strong>: This article is about building custom applications, like almost all of my client companies are doing. It is only partially applicable to writing framework\/library code.<\/p>\n

Sadly, 25 years later, checked exceptions are still here.<\/p>\n

Only use Runtime Exceptions<\/h2>\n

Imagine the following (overly?)simplified configuration loader:<\/p>\n

class Config {\n   public static Date getLastPromoDate() throws ParseException, IOException {\n     Properties props = new Properties();\n     try (Reader reader = new FileReader(\"config.properties\")) {\n        props.load(reader);\n     }\n     SimpleDateFormat format = new SimpleDateFormat(\"yyyy-MM-dd\");\n     return format.parse(props.getProperty(\"last.promo.date\"));\n   }\n}<\/code><\/pre>\n
(Disclaimer<\/strong>: config files shouldn\u2019t be read repeatedly but cached somehow; this is just a simplified example to illustrate some standard exceptions occurring.)<\/p>\n
And here is the business logic code using our Config<\/code> class:<\/p>\n
public void applyDiscount(Order order, Customer customer) {\n try {\n   if (order.getOfferDate().before(Config.getLastPromoDate())) {\n      System.out.println(\"APPLYING DISCOUNT\");\n      order.setPrice(order.getPrice() * (100 - 2 * customer.getMemberCard().getFidelityDiscount()) \/ 100);\n   } else {\n      System.out.println(\"NO DISCOUNT\");\n   }\n } catch (Exception e) {\n   \/\/ TODO\n }\n}<\/code><\/pre>\n
The Diaper Pattern<\/h3>\n
Have you ever encountered an empty catch<\/code> block? One in every 10 developers attending my training sessions found this in production code at some point in their career. This terrible mistake even got a name:<\/p>\n
\n
The Diaper Anti-Pattern<\/strong> = catching all exceptions and just silencing them.<\/p>\n<\/blockquote>\n
I would name it “shawarma-style error handling”<\/strong> when explaining it to younger developers for two reasons. First, you don’t know precisely what exception you swallow. Secondly, shawarma-maker becomes a possible future career path if you regularly apply this technique (I\u2019m evil here, right?).<\/p>\n
But let me explain why.<\/p>\n
In production, when the applyDiscount()<\/code> method above got called, it abruptly terminated for some orders without printing neither APPLYING DISCOUNT<\/code>, nor NO DISCOUNT<\/code>. Can you figure out what happened for those orders?<\/p>\n
Yup… a NullPointerException occurred in the if<\/code> condition for the Orders having a null<\/code> offer date, but then the exception was hidden by the Diaper Pattern. You can experience it yourself by running the InProduction<\/code> class from this commit<\/a>. By the way, I wrote another blog post<\/a> about how to avoid NullPointerException<\/code>, using Optional<\/code> and a self-validating data model.<\/p>\n
But the real-world code is never this simple, and you can waste hours to find such a swallowed exception in typical production code. You will probably have to breakpoint around, as there’s nothing in the logs. This is bad, very, very bad.<\/p>\n
But how did the code end up like that?<\/p>\n
First of all, you can selectively catch multiple exceptions using the syntax catch (ParseException | IOException)<\/code> only since Java 7, released in 2011. For a large successful Java application, ten years is not so long ago, so the author of the code might have caught Exception<\/code> because he didn’t want to repeat an identical catch<\/code> block (one for ParseException<\/code> and one for IOException<\/code>).<\/p>\n
Okay, but still, why is the catch<\/code> block empty ?!?<\/p>\n
Eh… that’s another story. Three years ago, they might have sent an email to ask how to handle that exception, or they might have just rushed and forgotten to handle it. Or perhaps one of the exceptions they caught there was regularly popping, polluting the log every minute.<\/p>\n
In the case of repeating exceptions, I would log that exception on the TRACE<\/code> level, as you can decrease the log level in production without a restart if needed, via Spring Actuator<\/a> or via a Logback JMX Bean<\/a>. But before doing that, I would first try to prevent that exception from occurring by doing some pre-checks. If that\u2019s not possible, I will make sure I catch and log.trace<\/code> that exception exactly around the line throwing it. Be very cautious with ignoring exceptions or logging them at a low log level!<\/p>\n
You would never swallow exceptions, I know.<\/p>\n
As a matter of fact, even the catch block auto-generated by Eclipse or IntelliJ would .printStackTrace()<\/code> by default, so you\u2019re safe, right?<\/p>\n
By the way, here\u2019s a fun fact for you: .printStackTrace()<\/code> prints the exception to System.err<\/code>, not System.out<\/code>, and by default, most frameworks (Spring Boot included) don’t capture System.err<\/code> to the log file unless you take explicit steps<\/a>. So despite e.printStackTrace()<\/code>, you will probably won’t see anything in your log<\/strong> file. Oops!<\/p>\n
But let\u2019s come back to our beloved NullPointerException<\/code>. By the way, do you know that songs were written for this exception? (and other hard to trace exceptions in general)<\/p>\n