Error Handling ft. Clean Code

Clean Code….Naam to suna hi hoga (Famous SRK dialogue). A book which is followed by many engineers to write perfect code. Today we will cover Chapter 7 : Error Handling . The purpose of this post is to make a summary of the chapter so that you can revisit it quickly. I strongly recommend to read the chapter entirely, this is just for revision purposes. So let’s begin.

Code can get abnormal inputs, device can fail, connection can timout and what not. Handling errors like this is important. But more important is handling them “Cleanly😉”. Here is the summary:

Using exceptions instead of Error Code:

1. Using error codes returned from the callee function leads to branching in the caller functions about all type of error code which messes the main logic of the call function.

WRITE YOUR TRY-CATCH-FINALLY STATEMENT FIRST:

1. Write down Try Catch Finally first. It helps to know what goes in each of them and makes you put logic accordingly.
2. Write Unit tests of try-catch-finally, it will help in getting the right logic in the right block.

Checked Exceptions:

1. Checked Exception breaks open/close principle, encapsulation.
2. Its maintainability is a bit hard as adding a new exception in a function makes you change all the functions which are calling it.
3. Not many languages have this type of exceptions and still we can write robust softwares in them.
4. Useful only for some critical libraries.

PROVIDE CONTEXT WITH EXCEPTIONS:

1. Don’t just log the stack trace, send a meaningful message which can help most after seeing that error. Best ones are which contain the values in the object and a short description why that flow was triggered.

DEFINE EXCEPTION CLASSES IN TERMS OF A CALLER’S NEEDS:

1. You can throw 10 different exceptions but the caller function takes only 2 types of actions on this 10 types of exceptions. So it’s better to throw only 2 types of exceptions instead of 10.
2. For the existing library classes, we can use a wrapper class, which can take this 10 exceptions and convert them into 2 exceptions.
3. Using one type of exception is enough as the error message can describe more about details of exception. Using multiple types of exception is helpful when we want to skip one of the exception type.

DEFINE THE NORMAL FLOW:

1. Sometimes the caller might need to call another method of callee class upon receiving exception from function F of callee class. A callee class can handle this case in function F by calling its other method internally and make the code flow for the caller function simpler as it dont need to call another method of it in the catch block.

Don’t return Null:

1. A caller function dont know what to do when you return NULL.
2. Better throw an exception, default object, empty list etc.
3. If you are calling an api returning NULL, create a wrapper class over it to simulate point no 2.

Don’t Pass Null:

1. When you pass a NULL pointer what do you expect a function to do? Unless callee function demands for the NULL value don’t pass it.
2. When passed a NULL value max it can throw a null pointer exception if it has checked for NULL args. Else we will get a NPE. Hence better to avoid passing NULL.

Thanks it,

Hope you liked it,

If you have any feedback, please feel free to comment or reply to the email.

If you like this and want to read more, please share this and subscribe Newsletter .

Find me @darshan_kadu