Should your code really throw exceptions? People and Thoughts

I absolutely love keeping meaningful things that our brain chooses to discard and think about those. One of such things has been an opinion of one of my all time favorite and inspirational colleagues Mr. Amitabh Jain. We used to talk about tech during our lunch times and one of his opinions kept ringing bells for me .. He always used to dislike notion of try … catch blocks in programming.

He would always say that writing try .. catch is not a good practice.. not that you should never have try…catch but his opinion was more about trying to minimize it as much as one can. He used to say that using try … catch is no less than making your system more error prone.

I was too junior at the time, so everything he would spit out about technology was a gold. So I used to try to grasp it as much as possible. Either knowingly or unknowingly… And somehow, I was on his side for this, that you should not really need a try catch block…

As much as I understood back then, my take on it was that by introducing try catches in the system is simply like you expect something somewhere, you don’t get it right, so you compromise and proceed without it and that causes more problem going ahead, because your compromise on the value that you expected there is after-all a compromise.. some programmer along the line would have to consider routine for compromised value as well and if he forgets that by mistake, the code is going to break there.. so either-or, it’s going to break.

Every now and then I used to think on this topic and just now, I actually got fare intuitive examples where what Amitabh sir said made sense.

I was listening to one of the talks at Google about software system design, and the speaker really had some good examples. He, as one of his ideas, said, ‘You should really limit the number of exceptions you design in your system’. And that’s because, according to him, with all those enormous amount of exceptions that we write, we make simple things harder to implement. We unnecessarily introduce complexities in the system.

One of the best examples he gave there, was one of the Windows behaviors. A behavior that you can’t delete a file that’s currently being accessed by some other program. Such a nightmare… Because now every other program has to handle the case that somebody might be accessing the file.

According to him, rather than having 100’s of such exceptions to “file can’t be deleted because it’s being accessed by some other program”, what those guys could have done is to delete the file from directories and the namespaces and from everywhere so that it no more appears in the file system but the actual contents of the file still hang around, so that the other program that’s accessing the file still can, and then when the last open instance of the file is closed, it cleans up and throws away everything.

Such a lovely solution. There’s no error on each side, it just does the right thing. That’s what Unix does today BTW.

The other awesome example he gave was about, is “substrings”. All the indexing methods and substring methods in Java or many other programming languages are very exception happy. You gave them an index more than it’s length and they throw an exception. He finds this a huge pain..

According to him, simplest ways they could have done it better than raising the exception there is to return an overlap between the index range specified and the available contents of the string.

So exceptions make lot of value when you throw them the farthest. Crashing is a fine thing to do in certain situations than handling exceptions. Like in most of the programs I would argue, one should not catch out of memory exceptions. Because it’s so hopelessly complicated that if you depend so much on memory, simply just print a message and crash.

The alternative would create so much complexity that its even harder to do right things right. So yeah, what I would agree with is that it’s not that you should not have expectations.. there would be times when you will have to have an exception. But you should try to use try … catch as cautiously as you can.

Wow ! His talk was more than this but I think I would leave it here. Just wanted to stress on the fact that try… catch , to me, is just an excuse .. an excuse given by your program. Sometimes, its good but not all the times.

With this, I will leave the decision to you. “Should your code really throw exceptions?”

Think on it !!!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.