Tuesday, 21 April 2009

Top Gear Filming in Canary Wharf

Sorry to disappoint- a non technical post!

Today the Top Gear team were in Canary Wharf and I managed to take some poor quality photos on my mobile- if only I had my SLR! Luckily I managed to make them a little better by using Photoshop Elements.

Clarkson inspecting a car:


Hammond and May inspecting a car:


The trio looking at the assembled crowd:


Clarkson asking the crowd if anyone is a banker:


It was amazing how many people “worked” for the FSA when Clarkson asked them this question!

James May talking to people in the crowd:

Looks like someone else beat me to it putting pictures on the Internet.

Monday, 20 April 2009

The Obsolete Attribute

Today a former co-worker asked me “what was that attribute we used to mark something as deprecated?” After a little pause for thought I remembered it was the ObsoleteAttribute- It’s a shame Microsoft hadn’t named this DeprecatedAttribute instead- this is what the annotation is called in Java.

I had previously used this attribute whilst in the middle of a large refactoring exercise on a project, where other developers were working on existing classes. It served as a useful reminder to start calling the new method, without breaking the build/their code/unit tests (we had a team culture where we would address warnings as soon as we noticed them). After all the consumer classes had been modified to use the new code, I searched for “Obsolete” in the code and discovered that the previous development team (the project was initially outsourced) had been using comments to mark code as deprecated- so perhaps not many people know about this useful attributes existence?

By default the attribute generates a compiler warning when a program element is referred to in a consumer class. This is the way I had used the attribute previously with a textual description describing how to correct the warning. Indeed a first glance at the documentation for the class (see here in the C# language specification, and here in the MSDN library)  suggests this is all this attribute can do:

        static void Main(string[] args)





        [Obsolete("Use the BetterMethod instead")]

        public static void ObsoleteOne()


            Console.WriteLine("This is a bad method");



        public static void BetterMethod()


            Console.WriteLine("This is a better method");




Used in this manner, the attribute will caused a warning to be generated like so:


In our discussion on using the attribute my former co-worker pointed out that the attribute can also be used to create a compiler error, simply by changing the code to (notice the 2nd boolean parameter):

        [Obsolete("Use the BetterMethod instead", true)]

        public static void ObsoleteOne()


            Console.WriteLine("This is a bad method");


This will result in a compiler error as follows:


In my project I didn’t use this- when references to the old code were removed, I simply removed the obsolete methods. In an API which you distribute to multiple consumers, you obviously don’t have that luxury, and I can see this overload being useful. It is important to remember that this attribute is useful for classes, structs, enums, constructors, properties, fields, events, interfaces or delegates as well as methods.

Sun’s (or should I say Oracle’s) Java documentation provides some useful insight as to when you should deprecate code.

When deprecating it is important to suggest how developers using your code should fix the issue. For example if you use the deprecated class System.Web.Mail.MailMessage, you will receive the following useful compiler warning:


This tells the consumer that the method is obsolete, what the recommended alternative is and where to go to find further help- which unfortunately in this case seems to redirect to a generic .NET Framework page (woops)! I’m sure any competent developer can quickly work out that they should use System.Net.Mail.MailMessage instead though!

Friday, 17 April 2009

Excellent Slides on unit testing

Today I stumbled across some excellent slides on unit testing. Unfortunately they only appear to be viewable in Firefox, but they are certainly worth viewing. They cover a lot of ground including the reason for mock objects and an excellent explanation on the differences between unit testing and integration testing.

I’m also enjoying looking at stackoverflow- this site is an excellent resource for programmers, it is also an excellent example of what can be achieved with ASP.NET MVC.

Wednesday, 8 April 2009

Break execution on all exceptions

A colleague of mine informed me that she had been working on a hard to track down bug in an application written by another developer. After some investigation she discovered the bug was caused by invalid logic created by an exception that the original developer had decided to swallow.

This scenario is quite common and is documented as a common source of bugs in the excellent book Debugging Microsoft .NET 2.0 Applications by John Robbins. It would probably be better if the debugger breaks on all exceptions by default with Just My Code, that way those hidden bugs would become more apparent during development.

In order to get the debugger to break on all CLR exceptions all you need to do is the following:

  • From the Debug Menu choose Exceptions or CTRL-ALT-E (screenshot from VS.NET 2008):


Select Thrown for all CLR exceptions or expand the tree view to only break on specific exceptions. You can then debug your app and hopefully (if it is well written), the debugger shouldn’t normally hit anything that isn’t a breakpoint!

This Visual Studio debugger feature is useful for a number of scenarios, notably:

  1. Ensuring that the application is not catching overly general exceptions.
  2. Locating difficult to detect bugs (these can also be caused by 1).
  3. Optimizing performance.

Of these 3 scenarios optimizing performance is worth discussing. When I first learnt about this feature, I tried it out on a large application that I was assigned the task of maintaining (disclaimer- I wasn’t in the original programming team :-).

The application was a .NET 1.1 application (I was in the process of upgrading to 2.0- as I always strive to upgrade to the latest available framework/toolset where possible/feasible) that conceptually did something along the lines of:

string hopefullyANumber;

// Assign the string from somewhere...


int result = 0;



    result = int.Parse(hopefullyANumber);


catch (Exception)


    // Swallow   


return result;

This code would not of caused any real performance issues, were it not for the fact that it was being called over and over thousands of times!

Admittedly the original developers didn’t have access to Int32.TryParse (but they could of used other techniques such as regular expressions), however after modifying the code so that it used TryParse I managed to reduce the CPU usage of the application by over 20% (I profiled it before and after with dotTRACE)!

It is good practise to see if the TryParse or Tester-Doer pattern can be of benefit to the performance of your application.

In summary having the debugger break on all exceptions in applications is a useful technique to catch bugs early in development, to check for over generalized exception handling or to enhance performance.