Exception Handling

In this post I’d like to share my personal preference of handling exceptions.

I’ll be frank I don’t like to handle exceptions at all. I always prefer to prevent exceptions rather than handling them. It’s not possible to write the perfect software but we can certainly try and thrive for that. For example if you are making a calculator you are expecting numeric values. Instead of handling non numeric values it’s better to ensure that users can’t input unwanted values. So in stead of handling exceptions we prevent it from happening.

It’s not possible to prevent arithmetical errors. Such as dividing something by zero or executing an operation that has no mathematical definition. I still haven’t figured out a way to prevent these let me know if you have.

While I’m in developing something I always avoid writing Try Catch Blocks. The main reason I do that is I don’t trust my own code. Because I’m human and humans can make mistakes. Whenever an application throws an exception it’s certainly something to be fixed today/tomorrow/100 years later. If I hide my exceptions behind a try catch block I’ll most likely never notice the exception. So when ever my application crashes I get happy instead of getting upset. Because Now I know exactly where my code can be better. And also I gain a new knowledge about the exception that occurred.

So what knowledge did I gain so far?

  1. Whenever my application throws an null pointer exception I instantly understand that I didn’t initialize a certain variable or I need to make sure the code doesn’t execute to next step for null
  2. Whenever I find an out of bound exception I carefully check the boundary condition of an array that I was iterating over.(I figured later that it’s better to use ForEach loop instead of worrying about indexes)
  3. Whenever I my application crashes and says, “File Not found” I realize I wrote some stupid code where I didn’t check if the file existed or not.

You might say “I can still find these exceptions if I put code in try catch block”. Well yes, Certainly you can. BUT you will find the bug sooner this way. Since your application will keep crashing until you fix it. And it will save a lot of time. There has been a lot of time that while developing a feature of a software we find a bug and fail to pinpoint the reason of it. Most often it occurs because of an exception somewhere. Maybe you are iterating over a list of data that comes from database but in the Database module there was an connection exception and there was no data. You will keep wondering why there was null in the list but until you debug step by step you can’t find exactly where the exception had occurred. But if you didn’t handle the code with try catch,as soon as there was an exception you would know since the application would crash there. Exception handling is for exceptional cases. If your application doesn’t run without Try Catch , You are probably using Try catch for unexceptional cases. Just because you can, Doesn’t mean you should. It’s always better to have your application crash a lot than deliver faulty outputs. An exception always changes your program flow. You can’t trust your own code after one exception has occurred.

I almost never use try catch during development phase. Only for EXCEPTIONAL cases I might consider. One such Exceptional cases would be math errors that’s certainly an exception. If I were to define Exceptional cases I’d say, If there is no possible work around for it, It’s Exceptional. No API call’s certainly aren’t exceptional. One way or the other API’s will return you something a status code? or a null data or something. Manage with those. File Exceptions ? Not found? Don’t have permission? Fix those. Don’t be lazy. Maybe 0.1% of the times you will find a faulty library function or Faulty OS feature Only then if you are 100% sure it’s a 3rd party bug that you can’t work around with, Go for a Try catch.

All that being said. Don’t forget to add try catch back before you plan to ship your software. You certainly won’t want your application crashing on your client’s face. But in alpha/beta releases try to avoid Try catch so that you can deliver a better software when you go live.