Musings by Generator

Development, Life and everything else in S.A.

Best Coding Practices – Exception Handling

I bet every developer says that they subscribe to Best Coding Practices but not many do, and those that do, normally only apply parts of it.

I do try to apply it all but, like most developers, I don’t always find it to be possible. I can handle not using naming conventions etc, but the one thing that really does get under my skin is proper exception handling.

It is not always practical to use try {} catch blocks as they can interfere, and cause more problems. Such as putting one in an event that is fired by a grid to do custom text for the displayed records. This is just painful to have to keep clicking on a message about an error several times.

When it is possible, especially when handling data (DataSets, DataTables, DataRows), exception handling should be employed. There is nothing worse than for a user to get an unhandled exception, which then forces the application to close or, as the users will put it, crash.

but the one thing that is worse than actually not using exception handling is doing nothing when an exception is thrown:

public void Error()
{
    try
    {
        DataRow errorRow = null;

        errorRow["ColumnA"] = "My error string";
    }
    Catch(Exception e)
    {}
}

This is infuriating for me since the application will function as expected even though the above code will always cause an error. Every developer has had a bug that makes them pull their hair out cause the application looks like it is working fine but they know something is off, and eventually they will find something like the above code and first scream for joy, and then start searching the subversion log trying to find out which idiot wrote such bad code.

If you don’t want to popup a message then send it to your application’s log, any developer worth with his salt will have a logging system in place, if you don’t have a logging system in your application, then just send it to the OS’ standard event logs.

Most applications have message boxes that fit in with the aesthetics of the application, in a project I am currently working on, we have completely built our own custom message boxes from the ground up and are not using the Standard .Net MessageBox.Show() at all. If you don’t have something like I do, then for crying out load use the .Net MessageBox:

public void Error()
{
   try
   {
       DataRow errorRow = null;

       errorRow["ColumnA"] = "My error string";
   }
   Catch(exception e)
   {
       MessageBox.Show(String.Format("{0} {1} {2}", e.Message, System.Enviroment.NewLine, e.StackTrace), "Application Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
   }
}

It may be crude, but at least the user knows that an error occurred and they can report it, and actually give you the developer something to work with when you get a bug report of “application threw an error on xyz screen” with no steps to reproduce.

The bottom line is this: If you don’t have some form of exception handling in place, you are just making your own life more difficult later on when it all seems to work except for the part when a user does one small action and it just “Crashes”.