Developing for Exceptions
The assumption here is that the unattractive step-sister of Test-Driven Development is ‘developing for exceptions’—or developing because of exceptions. The two are completely unrelated but, through my undisciplined messing around, put in the same family.
When building two or more loosely coupled components in tandem, one way to divide the labor is by successfully ‘defending’ one component against the others. The method of defense is catching exceptions and sending back meaningful messages using the same method communication when the system is running as expected.
By now, this may sound super-obvious to any developer building any distributed system using contemporary technology, but the opinion here is that these ‘defenses’ mentioned previously are taken for granted when you are building a SOAP-based thingy with a tool from Microsoft, Sun or IBM/eclipse. Not so for us RESTafarian developers.
We have to make a conscious effort to write exception handlers that wrap up messages in our XML-related data type of choice. And often we might think we are so great that we can build multiple components in tandem and worry about getting exception handling right later. Not so: my advice (which is advice first for me) is to set up meaningful exceptions sooner rather than later.
Getting back a message like “Object reference not set” will force you to resort to debugging. But where do you set your breakpoint? Should you start with the client—or the server/loader/broker—or one or more of the assemblies being loaded by the server/loader/broker?
It may seem counterintuitive to actually welcome an “error message” but this is my way of dividing the labor when there’s a one-man band playing all of the instruments. But this is not a big deal. Even when, say, Visual Studio developers are not building a SOAP thing they still may cause the IDE to generate a code stub with a bunch of “Method not implemented” exceptions in it. This is just another way of dropping a TODO message.