Java 17 Recipes

CHAPTER 9
Exceptions and Logging
Exceptions are a way of describing exceptional circumstances within a program. They 
are an indicator that something unexpected (exceptional) has occurred. For that reason, 
exceptions are efficient at interrupting the current flow of the program and signaling 
that there is something that requires attention. As such, programs that utilize exceptions 
judiciously benefit from a better control flow and become more robust and informative 
for the user. Even so, using exceptions indiscriminately can cause performance 
degradation.
Within Java, exceptions can be thrown or caught. Throwing an exception involves 
indicating to the code that an exception has been encountered, using the throw keyword 
to signal the JVM to find any code capable of handling this exceptional circumstance 
within the current stack. Catching an exception involves telling the compiler which 
exceptions can be handled and which part of the code should be monitored for these 
exceptions to occur. This is denoted within the try/catch Java block (described in 
Recipe 9-1).
All exceptions inherit from the Throwable class and can be defined in the catch 
clause of a try/catch statement. The JVM primarily uses the Error classes to denote 
serious and/or fatal errors. According to the Java documentation, applications are not 
expected to catch Error exceptions since they are considered fatal (think of a computer 
being on fire). The bulk of exceptions within a Java program are inherited from the 
Exception class.
Within the JVM, there are two types of exceptions: checked and unchecked. 
Methods enforce checked exceptions. You can specify the exceptions a method can 
throw in the method signature. This requires any caller of the method to create a 
try/catch block, which handles the exceptions declared within the method signature. 
Unchecked exceptions do not require a stringent convention and are free to be thrown 
anywhere without implementing a try/catch block. Even so, unchecked exceptions 
(as described in Recipe 9-7) are usually discouraged because they can lead to threads 
unraveling (if nothing catches the exception) and poor visibility of problems. Exception 

---

330
classes that inherit from RuntimeException are considered unchecked exceptions, 
whereas exception classes that inherit directly from Exception are considered checked 
exceptions.
Be aware that the act of throwing exceptions is expensive (compared with other 
language construct alternatives), and as such, throwing exceptions makes a poor 
substitute for control flow. For example, you shouldn’t throw an exception to indicate 
an expected result of a method call (e.g., a method like isUsernameValid (String 
username)). It is better to call the method and return a Boolean with the result than 
throwing InvalidUsernameException to indicate failure.
While exceptions play an essential role in solid software development, logging 
exceptions can be just as important. Logging within an application helps the developer 
understand what events occur without debugging the code. This is especially true in 
production environments where there isn’t the opportunity for live debugging. In that 
sense, logging collects clues on what is occurring (most likely what went wrong) and 
helps you troubleshoot production problems. Many developers utilize a structured 
logging framework to provide more robust logging for an application. A solid logging 
framework with a solid methodology saves many late nights at work wondering, “what 
happened?”
Logging for Java is very mature. Many open source projects are widely accepted as 
the de facto standard for logging. In the recipes in this chapter, you use Java’s Logback 
framework and the Simple Logging Facade for Java (SLF4J). Both of these projects 
together create a good-enough solution for most logging needs. For the recipes 
involving SLF4J and Log4j, download SLF4J (
www.slf4j.org
) and put it in your project’s 
dependency path. This chapter also touches upon the lower-level JVM logging added 
in Java 9.