Nick Harris

Archive for May 2011

Exceptions are Exceptional

When I started writing Objective-C I had been in the C# world for years.  The mantra that Exceptions are Exceptional was new to me.  But after 2 years of Objective-C, the idea of writing @catch anywhere freaked me out.

C# developers get this wrong… a lot….

My favorite example that I ran into once while debugging another developers code…

try
{
// ...
}
catch(System.Exception)
{
Console.WriteLine("huh...");
}

This was in a commercially released product.  Pardon the pun but that’s unexceptable.

But everything has its place.  And since going back to helping architect and develop a C# webservice platform, we’ve molded a pattern which uses custom exceptions to handle bad things that we know might happen but allowing other exceptions to bubble all the way up to the “this shit is broken – fix it” level.

The platform uses the basic three tier approach – data level/logic level/webservice.  The idea is that if any client developer using the webservice sees a 500 error from the webservice tier, then something we never expected happened in the logic or data tier and it’s a serious bug. Top priority fix.  Pretty basic idea right?

In our code design we concentrated objects that will be used across multiple applications – be they service applications, web applications or even unit test projects – into their own library.  We then added our our subclass of System.Exception.  Now anywhere in the solution we know if the exception was something we created and should handle accordingly, or if its a bigger problem.

On top of that we added our own error code to our exceptions and documented what each of them means. They’re segmented into ranges just like Http Status codes and returned to anyone using the webservice in the headers of the response along with a detailed error message.  You can run Firebug and see exactly why your request failed.

This approach also gave us the ability to correctly set the http status code to something a client application can understand.  I’ve run into so many webservices that return HTTP STATUS 200 OK with an html body that says “400”.  If you’re doing this, you suck.

With our approach we have a central place on each endpoint that returns the appropriate http status code with an error code the client developers program can recognize and provide the appropriate user feedback, along with a useful trace message the savvy developer can use to figure out what’s wrong.

It’s an “everybody wins” goal platform architects should strive for.  It also saves on the technical questions as well.

We already have numerous developers building on our platform with minimal technical questions to our platform developers since its all relatively self explanatory.  And as someone who would rather write code than answer questions… that’s pretty awesome.

Written by Nick Harris

May 10, 2011 at 5:26 pm

Posted in Uncategorized