Clean Code Chapter 7: Error Handling
Periodically I’ve been posting updates as I read through Clean Code by Robert Martin. I’ve posted summaries on his chapters about Naming Variables, Functions, and Comments. All of this info has been super helpful and I’m 100% sure that this is a book I’ll be returning to as I progress on my coding journey.
These posts are an effort to get the word out about this awesome book, but also to help me solidify some of the concepts in my mind so I won’t forget them. Hopefully this is helpful and feel free to recommend any other helpful software publications!
As a newer Python developer, I haven’t had too much exposure to writing error messages and dealing with error handling. I have never even used ‘try-except’ blocks before in Python.
This chapter of Clean Code dove right into this topic and made me rethink a lot of my cursory assumptions about the subject.
Now I’m thinking it might not be a bad idea to explore these concepts in upcoming projects. Below are a few takeaways from the chapter.
If Error Handling Obscures Logic, It Makes Things Worse
The best lesson I think I learned from this chapter: Error Handling can actually make things worse as opposed to better.
We all want to write dynamic, flexible code, but sometimes our attempts at doing this can make things worse. Programmers can be so eager to cover all of their bases by writing more and more error handling expressions but these additional lines of code can end up crowding out the code they wrote in the first place.
In particular, Error Handling that attempts to address multiple issues in the same block can end up causing just such problems.
Code that is clean and robust handles errors with grace.
Evidently, older computer languages didn’t have the option to include Error Handling, so many programmers had to make due with writing return statements. This turned things into a holy mess and thankfully is not as big a strategy for modern-day programmers. Throwing exceptions helps avoid sidetracking the program’s flow control.
Finding the flow control of a program means separating the business logic and error handling.
Whenever possible, programmers should pull out and separate concerns if they become tangled. Good exceptions parse out potential problem areas and address them one at a time so those reading the code can see a list of all the potential problem areas in a piece of code.
The book goes into depth in a later chapter on the importance of unit tests and the best techniques for writing effective tests, but this chapter does touch on TDD when it comes to error handling.
The big takeaway: Try to write tests that force exceptions. This will suss out the true logic of your programs. Then add behavior to satisfy tests.
While accounting for error handling is typically not as widespread in a program as writing tests, it’s helpful to know how these two should interact in a way that can be mutually beneficial.
Each exception should provide context, to help others determine the source of the error. To do this, programmers should create informative error messages that provide helpful feedback.
A handy thing to remember here is that you may not be the only person reading your code, so if the error message doesn’t make sense to you in a few weeks or months, why would you expect for it to make sense to anyone else?
Clean Code is readable, but it also must be robust. These are not conflicting goals.
I’ll be thinking about all these tips and more as I sit down to my next set of coding exercises. Error handling, like tests, should be something that facilitates robust, flexible code, and not just one more item in the long list of things that threaten to get in the way.