Hiding errors:
- Swallowing informative excpetions
- Returning a magic value instead of the error
- Ignoring errors
I’m sure many can relate this this experience: I’m using an application or a programming API. The code runs and returns. I move on. I find out later that the code failed, and the work was never done.
This scenario can kill an application’s reliability and reputation. When this happens, you don’t find out about errors until some time later. Because of this, you really can’t say that the application is working correctly at any point in time unless you explicitly investigate a log somewhere where errors are stored.
Hiding errors makes life harder. Finding out about errors when they happen makes for more reliable systems. I’ll give one quick example from the .Net Framework v2.0. This example uses C#.
string loweredUrl “/mypage.aspx”;
string loweredApplicationPath = “/myApplication”;
string appRelativeUrl = VirtualPathUtility.ToAppRelative(loweredUrl, loweredApplicationPath);
Console.WriteLine(appRelativeUrl.Length);
This seems simple enough. We’re using the VirtualPathUtility class to convert a url to it’s application-relative form. In this case, I’m passing an invalid argument in. The rule this method uses is that if the url is not a part of the given application path, it’s invalid. What does VirtualPathUtility do in this case? It returns NULL! I passed in an invalid argument, and it returns null. The more appropriate response would be throwing an ArgumentException. Because of this error hiding, I have to know the internal rules of this method and code around them. I can’t afford for this code to continue while appRelativeUrl is null. The next line would throw a NullReferenceException.
Because of the error hiding, my code ends up like this:
string loweredUrl “/mypage.aspx”;
string loweredApplicationPath = “/myApplication”;
if (!loweredUrl.Contains(loweredApplicationPath))
{
throw new ApplicationException(string.Format(“url {0} is not in application path {1}”, loweredUrl, loweredApplicationPath));
}
string appRelativeUrl = VirtualPathUtility.ToAppRelative(loweredUrl, loweredApplicationPath);
Console.WriteLine(appRelativeUrl.Length);
I have to do an explicit check and compensate for the undesirable behavior of the API.
If an error condition happens, I want to know about it. The term “fail fast” is very popular. It means that if the application encounters a condition where it can’t continue, stop now and output the exception information. Don’t have the application limp along until it crashes in flames. If you break your arm, you stop what you are doing and get a cast put on. Yes, you _could_ go to work if it’s not your mousing arm, but you cause less damage if you stop right away and address the problem.
