Try,Catch and Exception

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.

When do I use Try catch?

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.

Lazy Programmer

I would like to introduce myself as a lazy programmer.

I don't like to type a few lines and remove those again again until it works.

- Yeah I prefer to write codes only when I'm sure that's what I want to write. For this I do one of two things. I write down my thoughts on a piece of paper or something similar. Or I just think about in my head. Once I'm sure that this is what I want only then I write the code. Before writing a single class I think what's its purpose or what dependencies will it have or what other classes might be dependent on it. Or Is this class even necessary ? What properties the class should have. Why is this property even necessary ? Do I want others to know about this property ? No? then make it private . Does this property need to be modified? No? make it read only. Same goes for functions. If I think any function that doesn't require external access I'd make those private. How this helps you might ask? Since I'm lazy I don't wanna remember how this class works. I make the class name obvious. Make sure the public functions/property names are self explanatory. So that I can totally forget how this class works. When I need I just create an instance and see what functions it offers.

Function and Property names.

- Since I'm lazy I don't wanna come back and rename the A() function or BB_ variable or property that I wrote down in a hurry later. Because Coding in a hurry would just add more work time later. Because If I ever have to come back to the code(Which I always have to) I'll be at a loss. Because the names of the function or property will make no sense at all. So To save later work I'd rather write down the names properly now which might cost me 1 extra second now that will save 1 minute later.

Reusable Functions

-Every time I write a function I ask myself what possible usages it can have. Because right now my function my just do one task but it might need to do bit more later. Suppose I'm writing a function that inserts a data into a file.Lets call it WriteToFile(). Now I ask myself should it be a void function or it should return a boolean of it's success. It'd be easier to just write a void method and just be done with it. But then it hit my mind that since it's a write to a file operation it could throw some exceptions like not being able to open or write file due to access restrictions. But my function here wouldn't know that.It's just going to throw an exception. Which I'll have to find later and tear my hair. So instead of solving that later let's fix it now. I'll make this a boolean function and put a try catch block if any exception occurs I'd return false otherwise the file has been written successfully so I can return true. If I want to go one step further I'd also put an out parameter(C#) to the function to send the exception as well. So how does it help? I can use that WriteToFile() Like before but now I have one more option available to me. I can check if the function has successfully written the file or not. And show the users appropriate messages. I couldn't do that before if I had a void function. In case there was an exception the application would just crash. From my experience It's always good to avoid void functions. If you are writing a void function you are just  going to add more work later.

Stick to one convention

-I always stick to one convention. I'm not talking about naming conventions only. I'm talking about everything we do in a code. For example I always write properties at the top of the class. If the class has way too many properties I group them into sections and comment them out so the groups stand out . Why? This helps me find those later. Since I'm lazy I don't wanna waste my time scrolling up and down. After I have written down all the properties I go on defining the methods. I make sure the methods are grouped together as well so that similar methods are near one another and In case I ever need to go through it, it should be near my hand.

Being lazy at coding doesn't mean not writing code. It means Write your code properly and efficiently so that you don't have to waste your time over old codes.

A STITCH IN TIME SAVES NINE