One of the most powerful, but misused logical constructs in programming is the exception. Exceptions provide the programmer with an exit strategy in the event of a runtime error. Any section of code that could fail should be wrapped in a "try" block. If an error occurs within that "try" block then an exception is thrown and any code in the subsequent "catch" block will get executed. Conveniently, in most languages that support exception handling, the reason for the failure is also passed into the "catch" block. This allows the programmer to check why the failure occurred and handle it appropriately.
Unfortunately, more often than not, programmers either simply ignore the exception and move on or pass the exception on to the user and exit the program. You will see this on far too many websites. No user should ever be exposed to an exception. In my mind, displaying an exception to a user is the programming equivalent of dropping one's pants.
Most programming languages that support exception handling offer a third optional code block known as "finally". The "finally" code block is always executed after the completion of the "try" or "catch" blocks. I have seen far too much code in my career that contains no "finally" block, but does contain duplicate code in both the "try" and "catch". In extreme cases I have seen complex code within the "catch" block that is highly likely to throw its own exceptions under certain circumstances. Any code within the "catch" block should be as simple as possible.
Consider the following ASP.Net C# console application. This application accepts commmand-line arguments and displays them back to the user. A common command-line structure accepts arguments that begin with a dash character ("-") as options with parameters immediately following. For example, "hello -name Brad" would tell the "hello" application to accept a "name" parameter with the value of "Brad". For web developers this is similar to the querystring.
A console program consumes the arguments in a globally scoped array called "args":
static void Main(string[] args)
Total number of command line argument values: 5
Arguments...
name=Brad
LiveResponse
color=Red
Total number of command line argument values: 4
Arguments...
name=Brad
LiveResponse
Exception: Index was outside the bounds of the array.
for (int i = 0; i < args.Length; i++)
{
if (args[i][0] == '-')
{
Console.WriteLine("\t" + args[i].Substring(1) + "=" + args[++i]);
}
else
{
Console.WriteLine("\t" + args[i]);
}
}
So now we have a program with a runtime error that is easy to produce. Why did I choose to demonstrate this with a console application? Any time you run a console application from the debugger it will simply exit when it is done. A program like this runs so quickly that you may never see it execute. In order to see the program execute you will need to insert logic that causes the program to wait before closing. In this example I added:
Console.ReadLine();
for (int i = 0; i < args.Length; i++)
{
if (args[i][0] == '-')
{
Console.WriteLine("\t" + args[i].Substring(1) + "=" + args[++i]);
}
else
{
Console.WriteLine("\t" + args[i]);
}
}
Console.ReadLine();
Console.WriteLine("Exception: " + ex.Message);
Console.ReadLine();
finally
{
Console.ReadLine();
}
Consider another example of an application that opens connections to a database. These connections must be closed. By placing the close methods within your "finally" block you can ensure that the connections don't remain open in the event of an error.
The "finally" block allows you to simplify your program by placing any actions together that must get executed every time, whether there is an error or not.
The whole example program follows. If you would like to see it in action, create a C# console application in Visual Studio and replace the program code with this. I intentionally wrote this program with an error in it. Try it out.
- Run it with a variety of command-line options and see how many ways you can break it.
- Move the "Console.Readline();" statement into the "try" or "catch" block to see what happens.
- Add a "throw" statement into your "try" or "catch" to see what happens (hint: a "throw" in the "catch" block produces very interesting results).
- And, for fun, see if you can write a more robust and terse command-line parser and post it in the comments below.
using System;
class Program
{
static void Main(string[] args)
{
try
{
Console.WriteLine("Count: {0}\r\nArguments...", args.Length);
for (int i = 0; i < args.Length; i++)
{
if (args[i][0] == '-')
{
//If the argument begins with a dash, include its parameter
// in the output.
//If the last argument begins with a dash this line will
// throw an exception.
Console.WriteLine("\t"+args[i].Substring(1)+"="+args[++i]);
}
else
{
//Otherwise just write the argument
Console.WriteLine("\t" + args[i]);
}
}
}
catch (Exception ex)
{
//The above code with throw an exception
// if the last argument begins with a dash.
Console.WriteLine("Exception: " + ex.Message);
}
finally
{
//Whether an exception is thrown or not this line is
// always executed.
Console.ReadLine();
}
}
}
