As you grow in your career you come to realize that people dont handle exceptions well. No matter how much you guide them, its just done. To be honest with you, its not a problem with them. Correct and easy guidance is missing. Without the right guidance, a dev has the following behaviours
– try catch is a pain
– i do it only if the api i am calling wants me to
– i totally avoid written a exception of my own
– i catch “Exception”
– i’ll clean this up later, now I need to get this code checked in and delivered, its really late.
These are all symptoms, not the root cause of the problem.
The root cause is,
– I dont know how try catch helps me in coding
– If I write my own exceptions, what benefit do I get
– I dont see a reason to know why this is important now, I can do it later
My guidance to them is 2 fold,
– Exceptions to be thrown if we want to communicate to a developer that he has done something wrong with your code. For example, you have written a base class that expects certain data from the derived class. At the point of using that data, you should throw a null pointer exception if that data is null.
– Exceptions are “communication”‘s to developers, NOT to customers. Ideally all unit tests should cover catching exceptions.
– Your fellow developers should know immediately that a nullpointer exception on a variable means that they should have initialized it before using it.
– As a good developer, you generally write code that needs to be written only once, the first time. You dont have the habit of postponing quality for excuses. Once people see that your code works really well, they will start giving you the time you need to deliver quality code. So “dont give in to pressure”.
– When confused, ask your self. Does this error need to be seen by a customer or your fellow developer. If its customer, then show a error message, and end gracefully. If fellow developer, then throw a exception.
Hope this article gave you some indication and guidance.