Handle Exceptions like a Professional (Part 1)

I still remember struggling with exceptions as a young developer. I didn’t understand when and how to use them.

If you are having trouble getting your head around exceptions, then you’ll want to read this article.

I was told more than once by more experienced colleagues not to abuse exceptions.

For example, I might have had to validate the password on a login form. When the user got the password wrong then should the password checking method return an error code to the calling method or should it throw an exception?

When asking a senior developer for guidance, I don’t remember any of them ever encouraging me to opt for the exception. The answer invariably was along the lines of “No, this is not an exceptional situation. People get their password wrong all the time. Don’t use an exception.” OK, fine. No exception.

On further consideration, I found this answer lacking. If getting your password wrong is not exceptional, but at least somewhat expected, then what kind of situation was now genuinely exceptional? A remote service returning an HTTP 500 Internal Server error? Once-in-a-hundred-years flood? Winning the lottery?

To some degree, all these scenarios are plausible and therefore expected.

I was getting nowhere fast. I felt that the use of exceptions by developers should have little to do with how improbable a particular scenario was.

As I gained development experience, it slowly dawned on me that the benefit of exceptions derived from something entirely different. It’s all about how exceptions work.

An Illustrating Example

Let’s return to the password validation scenario I faced as a junior developer.

We’ll consider two ways for how the password validation code could communicate ‘incorrect password’ to the UI. First, we’ll be returning an error code, and then we’ll throw an exception.

Returning an Error Code

1. The password checking method returns to the calling method a success code when the passwords match and an error code when they do not match.
2. The calling method would need to check the return value for an error code. If it is an error, like ‘invalid password’, then again return early to its calling method.
3. And so forth, up the call stack, for all methods, until,
4. Finally, a method will take the error code and convert it to a useful message to the user.

Problems with this approach:

• Unnecessary Complexity. We require the return value checks and early returns even in methods that do not themselves care about the result of the returned status code. We end up writing extra, unneeded code.
• Extra Unit Tests. If you write unit tests (and you’d better), then you’ll need a few extra tests to cover off the early returns.
• Reduced Readability. These extra return value checks take away from the readability of the main flow of the code.
• Increased Fragility. Without a comprehensive unit test suite, it’s easy to imagine another developer removing some of these return value checks that seem to add little value. Now the application is broken and no longer behaves as expected.

Throwing an Exception

1. The password checking method throws an exception that communicates the ‘invalid password’ error situation.
2. Another method that is interested in these exceptions catches it and converts the exception into a useful message to the end-user.

Thanks to how exceptions work, any methods that are not interested in the exception are skipped over. They may remain blissfully unaware of the error condition and do not need to have any code for it.

Conclusion

Frequently exceptions are explained as being useful in ‘exceptional’ circumstances. However, the usefulness of exceptions derives primarily from how they change the flow of control in a programme. They offer the ability to shortcut between a method and even distant ancestor callers. Error conditions in a program often benefit from this shortcutting program control granted by exceptions.

In my next post, I will show how in object-oriented languages, like C#, Java, C++, we can create an Exception Zoo that allows for orderly and structured management of many exceptions.

If you enjoyed this article, please leave some claps — and a bunch of claps if you loved it! :) Thank you kindly.

Join my email list to fast-track your software engineering career.

When signing up, you’ll get my guide, ‘The Road to Master Progammer’, containing 3 powerful ideas to help you shorten your journey to expert programmer.