Mostly, deployment is done in two stages, firstly to a UAT box and then to a Live box.  Obviously the most efficient way to do this is to bundle your features into a solution which can easily be deployed onto any number of machines.  But, it does mean you have to make sure you’ve got everything right.  Untangling mistakes in your code can be a right royal pain in the arse.

By the time you’ve developed your solution, tested it out, deployed it to UAT and tested it again you should be fairly confident that when you come to deploy it on the Live server things should go pretty smoothly.  And, touch wood, to date things have gone smoothly.

But I still can’t get over that rush of adrenaline that comes with clicking “Activate Feature” after deploying the solution on Live.  In the second or two whilst the page waits to reload my mind runs through all the possible things that could go wrong and how long it would take me to unpick the changes my code might have got half way though.  Then the page finally loads…..

….. “Feature Activated”, phew!  Time for a lie down to clam my nerves.

try {
    //many lines of code
catch (Exception ex) {
    throw new Exception("Something went wrong dude!");
}

This is probably the single most un-helpful piece of code a developer can write.  All you are doing is making you life and future developers lives harder when it comes to debugging.  The whole point of the try…catch block is for times when you know an exception may happen and it allows you to gracefully handle it without the whole system crashing to the ground.

So lets have a closer look at what’s wrong with this code:

Too many lines wrapped

You wrap code in a try…catch block the idea is to only wrap the code that is likely to throw an exception.  Whilst it isn’t impossible, it does make identifying the offending line of code harder to find.  This may sound like a trivial reason to complain but when you have to deal with this day after day it does get a little tedious.

Indiscriminate exception handling

By catching exceptions of type Exception you’re really saying to developers that come after you “I don’t care enough about this code to know what exceptions might happen.”  In many instances different exception types can be handled in different ways.  I’m betting that the default response of most developers that catch Exception will be to throw a cryptic message at the user and drop out of whatever the method was – probably without clean up resources either.

It is possible to have multiple catch blocks that catch different exception types if you think that there are multiple types of exceptions that might be thrown:

try {
    File.WriteAllText"(@"c:\test.txt", "Hello world!");
}
catch (FileNotFoundException ex) {
    // do something
}
catch (SecurityException ex) {
    // do something else
}

This means that you can handle different exceptions in different ways.  Also, any type of Exception that you don’t handle gets passed up the call stack.

The exception isn’t handled

In this particular instance the exception isn’t handled, so why on earth put the try…catch block there in the first place?!  If all you’re going to do is throw a new exception or re-throw the old exception without doing anything you’re better off leaving out the try…catch block.  It just adds overhead to instances when it runs through without exception.

Original exception is masked

Again, in this example a new exception is thrown.  If you must do this then at least include the original exception as the inner exception (the exception that cause the new exception to be thrown).  The Exception class even has a constructor to help with this:

public Exception( string message, Exception inner )

Alternatively, you can throw the original exception.

New exception is generalised

By throwing the base Exception class you are forcing developers that use your code to have to catch exceptions of type Exception – see above for why this can be bad.  If you can’t find a built-in exception class to use, and there are many, create your own.  Visual Studio 2008 has a code snippet for creating an exception class, all you have to do is fill-in the blanks.

In an ideal world…

… I’d like .Net to have a similar method to java of having to specify (use attributes) what exceptions a method throws or catches.  This allows you to easily find out what exceptions may originate in a method your code calls, and let other developers know what exceptions your code doesn’t handle.  It also allows for pretty good compile time exception checking.  It means extra code has to be written but I think it results in better code.

Recently I’ve had reason to take an code library written in C++ and port it to C#.  Whilst I dabbled in C++ on a compilers course at university, I hated it then and I still hate it now.  I personally think it’s an abomination and should be consigned to the great garbage collector in the sky.   Whilst I can just about read the C++ syntax there is a lot that I don’t understand about it.

The library I was porting had semi reasonable documentation outlining what classes exist and their methods and a brief description of the overall usage.  This gave me a good starting point, however the documentation didn’t include example usages and expected results, for this I was forced to delve into the code.

One development paradigm I have been interested in but have been unable to find a decent project to test it on is Test-Driven-Development and this seemed like the perfect project to try it on.  So I set to work on the first iteration getting the test set up.   Without knowing exactly what results I should be expecting I was finding it hard going, so once again I dived back into the old code.

Thankfully, the developers of the C++ library had create a fairly comprehensive set of unit tests and with my limited C++ knowledge and a text editor with RegEx Find & Replace I was quickly able to convert their unit tests into NUnit based unit tests.

For example, what started out life as:

 1: void test_row_multiply_change(void)

 2: {

 3:  row r;

 4:  RINGING_TEST( ( r *= change( 6, "X" ) ) == "214365" );

 5:  RINGING_TEST( ( r *= change( 6, "1" ) ) == "241635" );

 6:  RINGING_TEST( ( r *= change( 8, "X" ) ) == "42615387" );

 7:  RINGING_TEST( ( r *= change( 5, "3" ) ) == "24651387" );

 8:  

 9:  RINGING_TEST( row( "214365" ) * change( 7, "5" ) == row( "1234675" ) );

 10: }

Quickly became:

 1: [Test]

 2: public void TestMultiplicationByChange()

 3: {

 4:  Row r = new Row();

 5:  Assert.AreEqual((Row)"214365", r *= new Change(6, "X") );

 6:  Assert.AreEqual((Row)"241635", r *= new Change(6, "1"));

 7:  Assert.AreEqual((Row)"42615387", r *= new Change(8, "X" ));

 8:  Assert.AreEqual((Row)"24651387", r *= new Change(5, "3"));

 9:  

 10:  Assert.AreEqual((Row)"1234675", new Row("214365") * new Change(7, "5"));

 11: }

Now, with a full set of unit tests at my disposal I was quickly able to bash away at the library and very quickly got working code without the need to trawl through ghastly C++ code.

Hooray for Test-Driven-Development and three cheers for Test-Driven-Porting.

ps. The library I’m porting is an open source library for Bell Ringing – yes I know I’m a geek but anyone that has followed everything else in this post must also be a geek .  Once I’m finished I will be releasing my code under an open source license as well, I just need to pick the right one.

pps. I may have exaggerated my hate of C++ a little.  I believe all languages have their place, even the esoteric languages like LOLCode.