Clean Code – Error Handling

This week, we continue our Clean Code discussion as we dive into the joys and pains of error handing.

Seriously, read this book!

Join us for more discussion by becoming a part of our Slack community by signing up at https://www.codingblocks.net/slack.

For the full show notes, visit:

Watch and Listen

Thanks to those that left reviews.
OMG, we hit the 1 *MILLION* download milestone!
Congratulations to Veselin for episode 50’s Clean Code giveaway.
It’s 2016, get out there an VOTE! (For the 2016 Software Developer Podcast Awards that is.)
Need stickers? Of course you do! Send us a SASE and we’ll make sure you get some. Click here for more information.
Special thanks to azeteg for audio template.

This chapter was written by Michael Feathers, known for “Working Effectively with Legacy Code” http://amzn.to/2hWUVtt
Error handling is important and needed, but if it obscures logic, it’s being done wrong
Use Exceptions rather than Return Codes
- Return codes force the caller to check the codes and act accordingly, which obscures logic
- Throwing an exception is cleaner as the logic isn’t obscured by the error handling
- Keeps the logic away from the errors – separation of concerns
Error handing and Go – https://blog.golang.org/error-handling-and-go
Start with your try catch finally statements
- Doing so forces you to think about the state of your application – you should be left in a good state if there is an error and that would resume in the catch
Try to write tests that FORCE exceptions
Then add behaviors to your handler to handle the exceptions
- This helps you maintain the scope of your try/catch’s
C# “using” has spoiled us!

A thing in Java that would force a developer to list all the types of exceptions that could be returned from a called method
Violates the open/closed principle
- Every method between the method being called and the calling method would have to include those exception lists. If you change what the called method can throw, you need to revisit every single method
Typically the costs / maintenance outweigh the benefits

Provide enough context with your exception to determine the source and location of the error – No more “Null Reference”
Stack trace isn’t enough – doesn’t identify the intention
Include messages along with the exceptions to help identify what the intention was, along with any stack / location info

Think in terms of how the exception will be used
- Don’t create redundant exception classes if they’ll simply be used to do the same thing, such as logging the error
- Think in terms of actionable exceptions
In the case of utilizing another libraries exceptions, if you’ll be doing the same thing for each type, write your own wrapper to simplify / reduce copies
- Wrapping 3rd party API’s are a “best practice” according to the book

Martin Fowler’s Special Case pattern
Visual Studio magazine’s take on The Special Case Pattern
The Null Object pattern
Don’t use catch’s to handle additional business logic flow
The book uses the notion of a meal expense. Get the meals.getTotal() catch that error if it didn’t exist and then add perdiem
- So, rather than return the expenses, return a MealExpense object that has a getTotal() method – if there were meals, then the MealExpense object getTotal will total the meals cost, otherwise it’ll return a PerDiemMealExpense that extends MealExpense

Says to use the Special Case Pattern – I think we’ve referred to it as the NULL object pattern?
NULL checks junk up your code and deter from the algorithm / application logic
If not doing a special case pattern, consider throwing an exception rather than returning null
If dealing with a 3rd party that returns nulls, consider the facade pattern and intercept and return an object
Poetry reading of Michael’s favorite poem: https://www.codingblocks.net/podcast/episode-10-csharp-6-and-roslyn/

Worse than returning null!
Just don’t allow methods to take in null parameters – will make your code much cleaner / more maintainable

Clean Code (Amazon)

We’ve been included in the 2016 Software Developer Podcast Awards. We’d _super_ appreciate you throwing a vote our way.

Share the joy