Exception Handling Isn’t Sexy
4 ways to improve how you should handle Exceptions
I’ll be honest, Exception Handling had never been and still probably isn’t at the forefront of my concerns when writing code. As a Junior Engineer I find that I am probably more concerned with speed over robustness of code. Which, needless to say, has led to a handful of issues. It was only during a recent lull period when I finally decided to take a closer look at how we were handling Exceptions (if we even were).
Like any other Engineer looking to learn more about a given topic, I turned to Google and realized quickly that while a standard ‘Best Practice' didn’t formally exist, a couple of common threads ran through them. I compiled just 4 of them (mainly for myself) in this article and hope that whoever stumbles upon this walks away just a little bit more enlightened.
But First, What is Exception Handling?
I won’t be going into the ‘formal’ definition here — there are many other articles out there which articulate this better. But to put it simply, Exception Handling is how ‘unexpected’ situations are handled in code. I put unexpected in quotes because technically, you would be expecting them, which is why they are being handled (unnecessarily convoluted? I agree).
Service:
Retrieve Book information from a database by titlePotential ‘Unexpected’ responses:
1. No record found for given title
2. No Database connection
3. Invalid input
As you can see, the situation above illustrates how a simple service which queries a database could lead to several of these ‘Unexpected ’ scenarios. The handling portion of it comes in when we think of how we are going to ‘deal with it’. What kind of response should we return to the User? How should our system recover from this Exception? What meaningful information would we need to trace the occurrence of this Exception? You get the drift.
4 Simple guidelines to keep in mind
These are just 4 of the many which I felt over-arched the mindset that should be taken towards Exception handling. By no means is this list meant to be exhaustive, but I believe they would serve as a good starting point.
1. Actually Handling the Exception.
Now before you click-away or scroll past, hear me out. While some Exceptions are obvious and come to mind more intuitively (like maybe 1/3 from the above example), others might lurk in the dark. For those who might not be very experienced, certain Exceptions will simply never come to mind because, you might’ve not encountered them yet.
“No Database connection”. An Exception surrounding a loss in database connection is not immediately evident because for the most part, it isn’t directly related to the core functionality of the feature.
While writing code (especially during a crunch), our focus might not be on identifying those lurking Exceptions, but rather, figuring out how best to optimize the given functionality. It’s hard enough trying to write code without ‘bugs’ — mistakes really, but it’s always pays long term to keep an active lookout. I’ve lost count on the number of times I had been interrupted because of poorly handled code.
2. Custom Exceptions
Hassle or not, Custom Exceptions can help significantly in the debugging process. Custom Exceptions allow you to add attributes and methods which aren’t already part of the standard Java Exception. Adding contextual information of why the Exception occurred will definitely help provide more meaningful feedback to both end Users as well as the Engineer — whom might not be yourself, so lets try to make things easier for everyone.
3. To Throw or Handle — that is the question
This was something I had on my mind while reading up on these practices. A situation I encountered often was deciding whether an Exception should be handled at it’s current layer or instead be thrown up one. What really helped me get a better grasp on answering this question was this reply;
‘.. catch the Exception when you are in the method that knows what to do’
I won’t go into details on explaining this because the above response explains it clearly enough, so do give it a read!
4. Pristine Clarity — Don’t be lazy!
When looking back at how we were handling Exceptions, I noticed that some of the messages came across as non-descriptive afterthoughts rather than ones which were intentionally thought through. Piggybacking off the second point, Custom Exceptions can only be effective if coupled with clear and descriptive Exception messages.
The approach which I found most helpful was the ‘context, problem, solution’ structure. To illustrate, we’ll borrow from the example above on Books —
Before
Invalid input, please ensure input contains valid charactersAfter
Context: Retrieve Book information with Title
Problem: Exception encountered when validating input Title
Solution: Ensure provided Title contains only alphanumeric values
While yes, this might seem a little long winded and excessive at first, I find that it goes a long way in helping both Users & Engineers better understand some of these Exceptions faced. So I recommend giving it a try! Your Exceptions will now be enriched with much more meaningful information for Users & Engineers to work off of.
So yes, those were the 4 tips which I found the most useful in framing the way I viewed Exception handling. If you’ve made it this far without clicking off, do leave me a 👏 if you’re up for it, if not I hope you at least took something away. And if you found that there were any other important practices which were not mentioned in this article (which of course there is), please do share it in the comments below! I’m very curious to learn what other ways there are to improve!
