Nick Harris

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…

// ...

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

5 Responses

Subscribe to comments with RSS.

  1. I’ve done something similar in my app’s code. When scanning a drive, it does it in pieces. If it encounters an exception (because it encountered something it wasn’t ready to recognize), it catches the exception, logs it, displays a message to contact the developer, but then continues. Prior to implementation of this, it would stop working all together, which was bad from a customer perspective.


    May 11, 2011 at 3:39 pm

  2. You basically explained what I have been doing with exceptions on C# the past couple of years. What I do with HTTP status codes is that I have a MyExceptionCode enum and I set a custom attribute to each one of the literals to associate them with a proper status code. I use an AOP layer which converts any of these known exceptions to the proper HTTP response.

    IMO attributes are the nicest feature C# has which other programming languages don’t.

    Gabriel Ayuso

    May 12, 2011 at 5:49 pm

  3. cool blog very informative keep it up…

    facebook for business

    May 24, 2011 at 8:51 am

  4. […] written and tweeted before about webservice API’s that make it difficult to figure out what […]

    Nick Harris

    June 16, 2011 at 4:19 am

  5. […] long ago I wrote about exceptions in Objective-C vs what I was doing with platform code I was writing for Glassboard in C#. I even […]

Comments are closed.

%d bloggers like this: