Why you should avoid Try Catch blocks

A try catch block is the ultimate “rescue” for a novice programmer. Got a problem you can’t fix? No problem! You can just put a try catch around it! Unfortunately in my experience that mentality always ends up biting you in the ass, mainly because you cannot simply “suppress” errors in your code. Try Catch blocking is what I commonly call the “bandage” approach to programming. You know you have a problem and you don’t want to fix it, so you just Try Catch it and off you go!

As tempting as it is to use a try catch block on a lot of things, and trust me I have this temptation constantly, it should be avoided.

So what are try catch blocks for anyways?

Try catch blocks are present in almost every modern language (as far as I know). They are there, now be very particular about this phrase, as a way to handle “code exceptions”. This means that when your code comes across an issue it cannot resolve, say parsing a “A” to a number, it skips over the rest of the try block and asks you “I have a problem I cannot solve on my own, what do you want me to do?”. This means, I must very much stress, that it asks “What should I do?” and not “What should I do, can I ignore?”.

Empty Catch? Your doing it wrong!

I see this over and over again. For some reason a lot of people just don’t get it. If you have nothing in your catch statement, you’re doing it wrong! When your code crashes, you need to handle that problem, there is no way out of this. A try catch block might be a temporary fix for whatever your problem is, but down the line it will cause issues for code that depends on whatever you did in the try catch (and did not execute all the way through). If I was getting a name out of the database and that record doesn’t exist, my database might throw an error saying “oops, can’t get record!”. If I decide to try catch it and not handle that issue, the name of my user is now blank or null. As a result the rest of my code is now executing without knowing something went wrong. Even worse I did not try to fix it. I have come across code numerous times that have an empty catch statement and then do something like this:



//Calls the database to get user


catch (Exception e) {}

if (userName != "" || userName != null)

the author simply doesn’t understand the concept of such code simply does not understand the concept of try catch

So why should I avoid them?

Because they are simply lazy and not worth it unless you really need them. In a lot of languages, Try Catch statements are expensive performance wise. You should be able to check if the the user exists first. Letting your code crash is like saying

Lets fly my plane, if the rotor falls off, then lets just handle the issue then and there. No need to check if the rotor is ok before we take off

The most common cause of exceptions is when data is inconsistent with the required input. Something is missing or something has not been provided (initialized or passed in) a long the way. The library or framework throws an exception as a way to tell you “hey, something is inconsistent, go fix it!” or “what you gave me cannot be processed, please check for valid input first”.

So what do you do? You check if what your putting into the system is valid. Make sure that the user does not enter a letter instead of a number. Or make sure that whatever is causing the exception internally is fixed or corrected. If statements are your best friend here.

So when CAN I use them?

Sometimes there is no way around it. If you cannot check if something is of the correct input you have to handle the exception yourself. But you HAVE to handle it. For instance if a socket closes in the middle of a data read or a write, it will throw an exception in the middle of the operation. As a result, you either need to change client state to something like “stand by” or try to smoothly close the connection and dump the resources. But you have to make sure that you’re handling things. One common approach I see all the time is empty try catching for inconstant data coming through a socket. The server spits out something you don’t like so you ignore it. Bad idea! If this happens you are not using the server socket connection for what it was made for or the server is not working properly. In either case, you at least in the moment of error have to inform someone about it and possibly close out of the connection. For this you would use the catch block.

Using a ternary operator (or short hand IF) in a LINQ statement

Today I have discovered that I need to use an if statement if statement inside my LINQ statement. It went something like this

Select an item from a list that holds codes for Blah objects. These objects hold two display texts for an associated code; a long text and a short text. If the long text is equal to a double quote mark, then display the short text

To clarify a little bit, I have list of objects for a drop down. The short text is displayed in the drop down from which, on select, I obtain a value which is a short hand code, ie. “SMNG” stands for “Something”. This way I can store the short hand code with the data record and store the associated information in a different table. When I need to figure out what the short or long text for “SMNG” is, I can just get it from the different table. If I need to change the wording to the short text for instance from “Something” to “Other”, I do not need to modify anything but the database table.

Ok, back to the code. A LINQ statement as far as I know does not allow you to hold the full if statement syntax. However, thankfully in C# they have included something called the Ternary Operator, or the “?:” operator combination (written as “operator” just like a “Do […] While is an “operator”) inherited from the C/C++ ways. In my case, just the statement would look something like:

longText = longText == "\"" ? c.shortText : c.longText;

Great! Now that we know the control statement that we want to return, we can do something like this:

(from c in codeList
where c.code == _status
select c.longText== "\"" ? c.shortText : c.longText).Single();

This LINQ returns a single item that I am looking for using my code. I could remove the “where” clause and just update them all but I decided to do it on a single basis.

Why this and not a “normal” if statement?

It has to do with how the LINQ statement sees it and the way the compiler sees it. This is not a real “If” if you will, but rather one that spits out a variable. A “normal” if statement does not return anything, its just a conditional. (Note: I am NOT saying that a ternary statement is a function, but rather a syntactical trick). In other words, to LINQ this just looks like a variable, nothing more, just as though I was passing in a normal variable. If I put a “normal” if statement in there, it has a few issues:

  • If statements have no return statements, it means that the compiler cannot guarantee something will be passed back in a select or a return
  • For raw LINQ, it is not syntactically convenient to implement something like a full if statements

Reguardless, if you find a way to do normal if statements in LINQ, please let me know!

C#: Using the Get/Set Effectively In Properties

One of the great things about C#, which I grew to love after switching from Java a few years back, are the properties. Properties allow you to use a Get/Set method right in the property which means you can use them like a variable (though .NET encourages you to call them LikeThis with a capital letter instead of a lower case). But why are they so powerful and effective? Well, lets take a look at an example. Take for instance one of the things I came across just today. Every time I compile my application for the Windows Emulator, it installs the application over the last one. This wipes all the files and directories I created on the previous run. This makes sense; it’s a new build so you have to run it as an application that’s just installed. This obviously means I have to make sure all my directories exist on start. One approach, is I can check if my directories exist before doing anything to them; this is cluttered and looks sloppy. Alternatively, this is where I can use the Get/Set of a property to my advantage!

I use a static variables in a GLOBAL class to hold persistent references. Doing this is somewhat deputed but I have found it is the most straight forward way to hold references you want to persist through the life time of an application. (Keeping it to ONLY data that needs to be persistent mind you! I’ll discuss the common mistake made by programmers with static variables in a different post)

Ok, enough talk. Lets go to the example. In Windows Phone 8, I can obtain the default application directory handle by doing the following (took me forever to find this by the way):

GLOBAL.JOURNEY_FILES_LOCATION = Windows.ApplicationModel.Package.Current + "/Journeys/";

For those who came here looking for “how to get root directory”, the above code is what you need to obtain your application directory in Windows Phone 8.

Back to the example; the issue here is that the directory doesn’t exist yet! If my user wants to load all the journeys (regardless if they exist) my application will explode with and IO exception. But wait! I don’t want to clutter up my code by checking if the directory exists EVERY TIME I do anything with the files. So how do I make sure that directory exists no matter what? With minimal clutter? Take a look at what the actual JOURNEY_FILES_LOCATION looks like:

 private static string _journeyLocation;
 public static string JOURNEY_FILES_LOCATION
            if (!Directory.Exists(_journeyLocation))
            return _journeyLocation;
            _journeyLocation = value;

So what have I done here? Well instead of having to call some function that checks if the directory exists and create one if it does not, I have the property take care of managing that itself. It’s encapsulated; I don’t have to bother with it ever again. I prefer to do things like this on the “get” of a property; most people prefer it to be in the set. Both are equal, with some down and up sides, but it will make sure that the directory exists. So what happens here? When I request to get the current directory, the get method goes in and checks if the directory exists and creates one if it does not. I don’t even need to bother with checking exclusively anymore! As a result, if the user wants to see all their current Journeys and the directory does not exist, it will ensure that the directory is created. Take this as an example:

public static JourneyObjectState RemoveJourney(string name)
     if (File.Exists(GLOBAL.JOURNEY_FILES_LOCATION + name))
         File.Delete(GLOBAL.JOURNEY_FILES_LOCATION + name);
         return JourneyObjectState.Removed;
     return JourneyObjectState.NotFound;

Why not just create all your directories on the start of the application?

You could and a lot of programmers will code that way. However its not the cleanest way to approach the issue. It’s also very prone to crashes, because if you forget to create one of the directories at the start or somewhere along the lines you delete the directory, your code has the potential to crash. This is what I call “air-tight” programming. I means that it ensures that no matter the the circumstances, your code will not crash the application. You’re safer checking if the directory exists every time rather than creating it and hoping it will not disappear.

Isn’t checking for the directory every time expensive?

Yes and no. We aren’t making a videogame here which has to access the file 30-60 times a second (and why would you code a game to do that?). Obtaining files is very fast via memory chips so I have don’t have much of a concern here. For instance the same application loads photos at one point and it is fast fast fast even on an emulator. This would become a burden if you run this on huge volumes of files but otherwise, this is not a performance bottle neck. Not in today’s age anyways.

Closing Notes

 Be careful when doing this for database records

I can see people having the temptation to hook up a database call to this. Files are fine but if you will slow down your application trying to call a remote database remotely like this. I would look for other ways to handle database interaction as this is expensive. For instance if you want to obtain a user through the “get”, this is not a good approach unless you make sure that you are not recalling the database after the user has been obtained.

Aaron Swartz; A small tribute

Unfortunately today I learned today Aaron Swartz is no longer with us. I will keep this blog post very short, but I thought I make a small tribute to him. He became a strong influence on web technologies at an early age, helping sculpt RSS 1.0 as well as played a key role in Reddit.com. Not a lot of people know him and probably will never, but this young guy fought for our information freedoms by putting a spotlight on JSTOR’s “premium” approach to academic material. If you don’t know him, please look him up. Unfortunately he is no longer with us.


Reddit’s Tribute Page

Using The Main(string[] args) Better

I have recently started a college class on Java. It haven’t worked with it in a while and thought maybe its a good choice as the last elective I have left to do. One thing I noticed is that a lot of the assignments and examples don’t mind if you cram your code into the

Main(string[] args) { [...] }

which is fine for those just beginning programming. For a lot of people just making code work is already a god send. However, I cannot help but point out that this is a fairly bad practice for a few reasons:

  • Any class scope variables have to be static
  • All functions have to be static
  • You have to initialize all your variables inside of the main function. Not a good practice.

This is not a very good thing because this is a pitfall for memory management. A program NEEDS to have a static entry point, but this does not mean that you need to wrap your code around it. If everything is static (which is something students LOVE to abuse), then the only time your memory gets cleared is when your function variables go out of scope and/or when the program exits. This is a bad coding practice which makes it very difficult to write optimized applications.

So what do I do?

You don’t have to do much. Simply create a non-static class and call it “Main” or any name you would like to give it. Then simply create a new instance of the variable inside the main and call a start function. Very simple! Let me show you an example:

     public class Main 
          //Now your class variables don't have to be static
          int myInt;

          public Main()
              myInt = 0;
              //Your variables initialization here

          public void start()
          //Put your code here!

and so your static main now looks like this!

public static void main(String[] args) {
      Main main = new Main();

Should I Teach This?

I started Java a about 6 years ago and for a very long time I did not understand how to structure code in an easy way. This concept might be a little bit confusing for students, but it will clean up their code. Students starting Java without coding experience still don’t understand what static variables are (and why you should avoid them), so this will help them avoid the pitfalls of “Well everything is static ill just make mine static too!”. It removes an extra element for something that is already somewhat confusing for many!

Closing Notes

        This helps exit your application better

Its not quite faster or “better” in the sense of exiting, but it nests your code in such a way where you know when your application is exiting. The only time your code will go beyond the “main.start()” is when it is exiting or switching states. This is extremely useful if you want to do some processing right before exiting.

Document and comment everything!

It is more often than not that I come across a lot of code that has absolutely no form of documentation. Thankfully most of the time I have access to the source code and I can figure out what is going on on my own. This however, is a waste of my time and resources; time which could be spent utilizing the code rather than trying to figure out how to use it.

Programmers are lazy; we have a lot of work and little time to do it in. More often than not, documentation is not a priority and will not make the cut before the software is due. As a result servicing your own software or someone else’s code becomes a burden rather than pleasure.

Imagine for a moment that you have spent the last three months working of a piece of software that will service 100 people in a company. The software is up to par with the requirements put forth by the customer and as it turns out, they are very happy with the results. Three more months go by and the customer comes to you again because something needs to be changed or even worse, upgraded. This is a common scenario a programmer has to go through if they have to work with clients. As a result of this cycle, there are two outcomes possible:

  • You have to go and build on top of the code you have already written to add the changes or add new features
  • Someone else has to do the job for you; someone who does not completely understand how your code works and yet must go in and make changes.

In either scenario, you are working with code that has to be reused. If you are the one in charge of making the changes, there is a very good chance you do not exactly remember how to utilize the libraries and code structures you have written. If someone else has to work with your code, they have no idea how your code can be utilized to create new functionality; even worse they have no idea how the code works internally, provided something goes wrong.

From my experience, many programmers don’t want to take the time to run through their code to add comments or write documentation. I can relate to that; I want to get stuff done and stopping to comment anything is well… time consuming. But no matter how much we flinch at the idea of commenting code and writing the appropriate documentation, it is truly a necessary bother.

It is safe to say that we can, most of the time determine what a function or a class is responsible for based on the signature of the function. To obtain an employee for instance, a function can look something like this:

        public Employee getEmployee(string ID) //Strings for ID is common, provided many databases hold them with 0's at the front

Looking at this we can safely say that this function provides an employee object based on the ID of the employee. Despite the simplicity of the example I can already outline a potential problem which can be solved by consulting the documentation. Going along with the fashion of providing simple examples, lets imagine that for this function the documentation is as follows:

getEmployee is an obsolete function that is used to obtain employees which carry the NNNNN ID number format. All employees currently have a new and old ID number. Because many of our applications need to be updated to a new ID number system, this function has not been removed until all our systems are upgraded. For the new system, please use the getEmployeeSomeNewSystem(string ID) instead

This can happen when a company obtains a new software package, for instance PeopleSoft which manages your back end infrastructure such as employee records. Because your old system is running out of ID numbers, it maybe that you are implementing a new ID number system while slowly porting over old applications to use it.

It is obvious that in the above example, you would probably know about this detail fairly well. However, as software becomes more and more complex it becomes difficult to keep track of these kinds of things.

Simple examples aside, it is most important to point out that everyone programs differently. Despite code standards, each programmers will still structure code differently, call things differently and approach coding problems differently. For instance it is common in video games that memory allocation becomes a serious consideration; after all, you are running your code at 25 to 60 times a second (depending on frame rate). A common way to try to curb the amount of memory an game uses to to use an object pooling mechanism. Once an object approaches the end of its life cycle, for instance a Vector3, instead of disposing of it you push it onto an object stack. When a new Vector3 is needed, if there are objects on that stack you simply pop one off and reuse it. This saves you on having to create a new copy (implications of doing this is for a different post). Though there are libraries that do this already, I for instance always like to write my own class for doing this. It minimizes overhead that large libraries have and reduces the complexity of the class to a few functions. Pooling, however, is not always a known approach to some programmers. Some of them might have to figure out what

//Pool has been instantiated somewhere else
SomeObject myObject = pool.resurect<SomeObject>();

does and why am I not just saying

SomeObject myObject = new SomeObject();

In this case I would provide a documentation and examples for the Pool class that takes care of managing object allocation. A programmer may or may not have seen this before, but regardless of that, s/he has to figure out if it is worth using this approach. Often we package off our libraries in DLLs and as a result, it’s quite frustrating to sift through some other solution to figure out what the hell this does. A documentation however, makes this very clear and straight forward and easily accessible.

Ok cool, but how to I approach this “documentation” stuff?

Everyone has their own approach to documentation; there is no golden rule to it. To me the definition of “good documentation” is documentation that makes it clear why this class or function exists and how to use it properly. But there are different types of documentation we have to consider. For instance, I do consider comments to be extremely important but they are not “documentation”. However, consider the following example:

/// <summary>
 /// Use these as the basis for your transformations. It is temping to allocate a new vector each time but it is very costly
 /// especially if you run your game on a mobile device
 /// </summary>
static class Vectors

In languages such as C# along with other .NET based languages, you can create what I like to call “internal documentation”. This is not the same as comments because when I call upon the Vectors class it provides me with the description. It holds transformation vectors such as [0 1] so that I don’t have to create a new one for computation. The class name “Vectors” can mean a few things. One might think it is for processing vector transformations, when it is actually just holds vectors for common use. However, because I have provided the <summary> information at the top of the class, when I call upon the Vectors class, intellisense will display the summary. This is most probably available in languages such as Java (along with an IDE that supports this), though I have not touched it in a while.

The other kind of documentation is written out documentation with examples. It is not part of the code and is normally found on some kind of resource. For instance a common place to store documentation are wiki’s that are restricted to only the development team. However, it does not have to stay internal. Almost every class in any of the Microsoft frameworks has examples, sometimes in multiple programming languages. This is probably the best resource a programmer can hand to another. If you are carrying a library from one project to another and have no documentation, you are going to have to go into the solution of a project that implements this and figure out how they implemented it there. This is a huge waste of time. In an off solution example, a programmer can generalize the implementation of a class so that you can use it for something else. If you go look at how someone else used it for something else, you’re gonna be stuck with the question

Well that’s great, but how do I use that class or function in general?

So, how do I approach this “commenting” stuff?

Rule of thumb I use; leave short but precise comments everywhere you can, but don’t tip the boat over with comments. Make sure they are constructive.

As a programmer, I don’t want to know why for instance, you created a list of employees unless there was some kind of serious decision behind it. For instance:

     //Create a list of employees
     List<Employee> employees = new List<Employee>();

Cool,  I am not learning how to code. After all “reading code” means I can see that this is a list of employees. However, if you do something like this:

       //This list is used for all employees, those pulled from the old system and the new system.
       List<Employee> employees = new List<Employee>();

This is A LOT more useful because now I know why you created a new list reference and initialized it with a blank list. This tells me that you have created a new list, to then you will it load with employees rather than re-point the reference to a returned list.

As I have mentioned before, comment as much as you can. Programmers can always read code well enough to soft through your written code fairly quickly but comments allow us to figure out why you created something a certain way. When there is a bug, I can quickly follow through with your comments and figure out where you went wrong.

To wrap things up

I think its about time I start wrapping this blog post up. However, I hope I have made a pretty good point; take the time to document. It will pay off in the end. If you work in a company that makes software, there is a pretty good chance you will be passing on your code to someone else. While you’re still around, you might get away with “Steve, how do I use this function properly?”. But has your code base grows and more and more people start using it, you can no longer answer everyone’s questions. You are now responsible for the efficiency of those around you and the quicker they can reuse your code, the better. One day you will not be there anymore and well, you might not care but some programmers do. After all, it is YOUR work that they are using in their software. If you ever have the chance to appreciate someone else leaving documentation for you to look at when they have long stopped working there, you will appreciate it.