.NET (C#)

Null Object pattern follow up

Scott Dorman — Fri, 04 Jul 2008 13:51:08 GMT

My earlier post on the Null Object pattern led to a few critiques about the fact that I was presenting an extension method to do what is essentially a very simple logical test, and, as a result, doesn’t provide much value.

For reference, here is the original extension method from that post

public static class NullObjectExtenstions
{
    public static bool IsNull(this object source)
    {
        return (source == null);
    }
}

Yes, this is an extremely simple method and performs a very basic logical test. However, consider the static IsNullOrEmtpy function on String (taken from Reflector):

public static bool IsNullOrEmpty(string value)
{
    if (value != null)
    {
        return (value.Length == 0);
    }
    return true;
}

I would argue that this is a relatively simple method and performs two very basic logical tests. What is the benefit to using IsNullOrEmpty? In a word, consistency. By using IsNullOrEmpty, I know that every time I need to perform this test it is executing the exact same code in the same order. I don’t have to worry about someone accidentally testing “Length == 0” before the “!= null” and causing a NullReferenceExcpetion.

This same benefit applies to the IsNull extension method. It introduces that consistency (although I agree this test is still very trivial) for testing nullability. As I mentioned in my comments, the better choice for the extension method would probably have been an IsNotNull method. Here is a more complete NullObjectExtensions class:

public static class NullObjectExtenstions
{
    public static bool IsNull<T>(this T source) where T : class
    {
        return (source == null);
    }

    public static bool IsNotNull<T>(this T source) where T : class
    {
        return (source != null);
    }
}

Technorati Tags: CSharp, .NET

What is “Defensive Programming”?

Scott Dorman — Fri, 04 Jul 2008 13:26:10 GMT

My post on the Null Object pattern has generated some interesting dialog. One of the trends that I have seen is the idea that defensive programming means your code should fail as early as possible. I couldn’t agree less.

According to Wikipedia,

Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software in spite of unforeseeable usage of said software. The idea can be viewed as reducing or eliminating the prospect of Murphy's Law having effect. Defensive programming techniques are used especially when a piece of software could be misused mischievously or inadvertently to catastrophic effect.

While this is a good definition, I think it still leaves much to be desired. The Wikipedia entry goes on to say that defensive programming is one approach to improving software quality by “Making the software behave in a predictable manner despite unexpected input or user actions.”

I think this is the closest definition that actually conveys what defensive programming is all about. The idea behind defensive programming is that the application should behave in a consistent and predictable manner even in the case of unexpected conditions.

There are a lot of different ways to achieve this and they are all different depending on what you are trying to accomplish with the code, the programming language, and the control structures being used. For example, considering a switch statement:

switch (Orientation)
{
   case Orientation.Horizontal:
      break;

   case Orientation.Vertical:
      break;
}

This is perfectly acceptable code, right? Remembering that enumerations are simply numeric (generally integer) values, it is entirely possible for this switch to get passed a numeric value that doesn’t correspond to either Horizontal or Vertical. In that case, there is the possibility of the switch, or code following the switch, to crash. One option to handle this would be to add a default case to the switch:

switch (Orientation)
{
    case Orientation.Horizontal:
        break;

    case Orientation.Vertical:
        break;

    default:
        break;
}

In the default case you could throw an exception (if that’s the appropriate behavior) or, more likely, you take some action that ensures either the remaining code doesn’t execute or at least doesn’t crash.

Looking at another example, this time casting, shows some other ways to program defensively. A common scenario for casting is in UI programming and handling events.

private void button1_Click(object sender, EventArgs e)
{
    ((Button)sender).Text = "You pressed a button";
}

Again, this code looks perfectly reasonable and will work just fine until someone accidentally assigns this event handler to something other than a button. Once that happens, the code will crash since sender won’t be castable to a Button. There are several different ways to handle this but the simplest (at least in my opinion) is

private void button1_Click(object sender, EventArgs e)
{
    Button button = sender as Button;
    if (button != null)
    {
        button.Text = "You pressed a button";
    }
}

Yes, it is a bit more code but it also guarantees that no matter what happens if the object that raised the event is not a Button, the code won’t crash. You could have chosen to throw an exception (or just let the exception generated by the runtime bubble up the call stack until it’s handled, but that may not be desirable depending on what you are doing.

The bottom line is that catching exceptions (not throwing them, but catching them…and all exceptions will eventually be caught, but possibly not in a way you intended) is expensive and if there are techniques that allow your program to continue functioning properly or otherwise gracefully handle exceptional conditions, known as “defensive programming”, you should opt for that approach.

Technorati Tags: .NET, CSharp

Null Object pattern

Scott Dorman — Sun, 25 May 2008 22:28:23 GMT

I've been trying to catch up on my reading and came across this post by Fredrik Normén where he raises the question about returning null or using the Null Object pattern. Interestingly enough, last month while I was in Seattle for the 2008 MVP Summit I had a very similar discussion. The end result of that discussion was that null objects, and nullability in general, ideally should be treated as a "first-class" citizen in the CLR. This means that if you try to execute a method on a null object you get a null back in return rather than a NullReferenceException.

I tend to follow a very similar philosophy as Fredrik in that I return null in some circumstances and empty collections (or other appropriate defaults) in others. I think this style has grown from the fact that nullability has never been a first class citizen in most programming languages.

A few of the comments suggested the use of an extension method to accomplish Fredrik's idea of an "IsNull" property. Since we only have the ability to create extension methods, I created an extension method called IsNull that extends Object Class (System) to see if this would work.

This is, perhaps, the simplest extension method I've seen and worked with. The extension method is:

        1: public static class NullObjectExtenstions

       2: {

       3:     public static bool IsNull(this object source)

       4:     {

       5:         return (source == null);

       6:     }

       7: }

Using this extension method is also just as easy. Here is a simple console application I wrote to verify that this does indeed work:

       1: class Program

       2: {

       3:     static void Main(string[] args)

       4:     {

       5:         string x = null;

       6:         List<string> y = null;

       7:         CultureInfo culture = null;

       8:  

       9:  

      10:         Debug.WriteLine(x.IsNull());

      11:         Debug.WriteLine(y.IsNull());

      12:         Debug.WriteLine(culture.IsNull());

      13:  

      14:         if (!culture.IsNull())

      15:         {

      16:             Debug.WriteLine(culture.DisplayName);

      17:         }

      18:     }

      19: }

The output of this application is:

True
True
True

The last call to Debug.WriteLine(culture.DisplayName) is never executed since culture.IsNull() returns true so we don't hit the NullReferenceException.

NameValueCollection and .NET Configuration Files

Scott Dorman — Mon, 17 Mar 2008 00:00:02 GMT

I spent most of yesterday trying to figure out how to make use of a NameValueCollection in a .NET configuration file. After wasting almost the entire night fighting with this problem, I thought I would let everyone know that it is possible, and easier than you might think. (By the way, this was a clear case of working too long on the problem. After a good nights sleep, I solved this in under 5 minutes.)

At this point you might wonder why this was so difficult. The largest and most significant problem is the fact that NameValueCollection isn't serializable (KB 814187). The reason for this is that NameValueCollection doesn't implement ICollection but extends NameObjectCollectionBase instead. The recommended solution is to use a SoapFormatter to serialize and deserialize the collection. While using the SoapFormatter does work, it seemed like a very complex solution for a seemingly simple problem.

Not wanting to over-engineer my solution, I started searching the web for alternatives. I found several newsgroup postings that all said to use the SoapFormatter since that was the recommended solution and the only way to go. Not having drunk too much blue kool-aid, I kept searching. That search turned up an article by Keyvan Nayyeri that shows how to created a serializable NameValueCollection. This approach was intriguing and certainly seemed to be a more useful solution than using the SoapFormatter, but again it seemed like a lot of work.

Keep in mind, all I wanted to be able to do in the configuration file was to create a section that looked like this:

        1: <copyFiles>

       2:   <add name="C:\Windows" value="*.dll"/>

       3:   <add name="C:\Temp"/>

       4: </copyFiles>

Continuing the search, I thought I found my answer. I stumbled across an article (".NET How To Create and Use Custom Name-Value Config Sections") that shows how to do this in 4 simple steps. Reading through the article, I realized that it is written using the the .NET 1.0 and 1.1 ConfigurationSettings, which is provided for backwards compatibility only. Since the application I'm working on is .NET 3.5 and taking advantage of many of the new language features, I wanted to ensure that I wasn't using any deprecated classes.

This is where I started running into additional problems. It seems that Microsoft provides a NameValueSectionHandler, which the article makes us of. The problem is that NameValueSectionHandler is architected following the .NET 1.0/1.1 model and implements the System.Configuration.IConfigurationSectionHandler interface. This is great if you want to use the deprecated ConfigurationSettings class; if you want to use the recommended System.Configuration.ConfigurationManager or System.Web.Configuration.WebConfigurationManager classes you are out of luck. They will only work with a class that derives from ConfigurationSection.

So, after all this I thought I was out of luck and would need to write my own configuration section handler. (Remember, this was about 1:00 AM.) After sleeping on it, I realized that there was a much simpler way. Along with the NameValueSectionHandler, Microsoft also implemented NameValueConfigurationCollection and NameValueConfigurationElement, which derive from the appropriate configuration classes to be used by the ConfigurationManager. After seeing that, I realized that all I needed to do was implement a NameValueSection which derives from ConfigurationSection.

This is where the solution becomes easy. In it's simplest most form, the NameValueSection looks like this:

       1: public class NameValueSection : ConfigurationSection

       2: {

       3:     [ConfigurationProperty("", IsDefaultCollection = true)]

       4:     public NameValueConfigurationCollection Settings

       5:     {

       6:         get

       7:         {

       8:             return (NameValueConfigurationCollection)base[""];

       9:         }

      10:     }

      11: }

As you can see, this is pretty simple. In order to use it, you declare the section in your app.config file:

       1: <sectionGroup name="customSettings">

       2:    <section name="copyFiles" type="NameValueSection, CustomConfiguration"/>

       3: </sectionGroup>

       4: <copyFiles>

       5:    <add name="C:\Windows" value="*.dll"/>

       6:    <add name="C:\Temp"/>

       7: </copyFiles>

To access this configuration section in code, you simply need to do this:

       1: NameValueSection nameValueSection = ConfigurationManager.GetSection("copyFiles") as NameValueSection;

       2: if (nameValueSection != null)

       3: {

       4:     NameValueConfigurationCollection settings = nameValueSection.Settings;

       5:     foreach (string key in settings.AllKeys)

       6:     {

       7:         Console.WriteLine(settings[key].Name + ": " + settings[key].Value);

       8:     }

       9: }

This is about as simple as it gets. Even though you aren't actually using the real NameValueCollection you are using the NameValueConfigurationCollection, which has almost identical behavior. This is the solution that I finally ended up implementing and it works great. As you can see, with a minimal amount of effort you are now able to use a NameValueCollection in your configuration files.

Technorati Tags: .NET, C#, NameValueCollection, ConfigurationManager

C# 3.0 - Partial Methods

Scott Dorman — Tue, 25 Dec 2007 00:51:55 GMT

Partial methods are a new feature available in C# 3.0 that don't seem to get enough credit. I think there was a lot of confusion early on about what partial methods were and how they were used.

Partial methods are intended to solve a major problem that is not only caused by code-generation tools and also affects those same tools. For instance, you are writing a code-generation tool but want to provide a way for the developers that are using your generated classes to hook in to specific areas of the code. As such, you don't want them editing your generated code since those customizations will be lost the next time the tool runs. On the flip side of this scenario is the developer who needs to write the code that hooks into those specific areas and doesn't want that code being lost the next time the tool runs.

Delegates are one solution to this type of problem. In the generated code, you declare a delegate method that you then call at the appropriate areas. If no one has implemented a concrete version of the delegate, the call will not do anything. However, if someone has implemented am instance of that delegate then the call will run the code in that instance. This sounds like a pretty good solution, and, until partial methods it really was the only solution. The drawback is that the code for the delegate is always compiled in to the runtime of your application and add to the runtime overhead of application (granted, that overhead is minimal but it's still there).

Partial classes helped with this problem by allowing the code-generation tools to isolate the generated code in a partial class. This allowed the developer to add their own methods to the class without fear that they would be overwritten the next time the tool ran. However, it only helped partially. In order to accomplish our scenario, you still needed to provide a delegate to allow the developer to hook into your process.

If we take this a step further and look at partial methods, you will start to see how they work and what the benefit is of using them. The following rules govern how partials methods can be declared and used:

Must be declared inside a partial class.
Must be declared as a void return type.
Must be declared with the partial.
Cannot be marked as extern.
Can be marked static or unsafe.
Can be generic.
Can have ref but not out parameters.
Cannot be referenced as a delegate until they are implemented
Cannot have access modifiers such as public, private or internal.
Cannot be declared as virtual.

Partial methods are implicitly marked as private. This means they cannot be called from outside the partial class.

Now that we have the rules out of the way, let's take a look at an example. This is a completely contrived example, as you typically wouldn't declare both portions of the partial class yourself.

        1: // This is the class that would normally have been autogenerated.

       2: public partial class CustomTypedCollection

       3: {

       4:     partial void BeforeAddingElement(CustomElement element);

       5:  

       6:     public void AddElement(CustomElement element)

       7:     {

       8:         BeforeAddingElement();

       9:     }

      10: }

      11:  

      12: public partial class CustomTypedCollection

      13: {

      14:     partial void BeforeAddingElement(CustomElement element)

      15:     {

      16:         Console.WriteLine("Element " + element + " is being added.");

      17:     }

      18: }

      19:  

      20: class Program

      21: {

      22:     static void Main(string[] args)

      23:     {

      24:         CustomTypedCollection c = new CustomTypedCollection();

      25:         c.AddElemeent(new CustomElement());

      26:     }

      27: }

In this example, the code-generation tool declares a partial method BeforeAddingElement. It is declared as just a function prototype with no implementation. Effectively, this tells the developer that if they want to hook in to the AddElement process, they can do so by declaring an implementation of the BeforeAddingElement method. If an implementation is declared, the implementation and the call inside AddElement will be compiled in to the runtime code. However, if no implementation is declared the call will be optimized by the compiler and it will be entirely eliminated in the runtime code.

This mechanism provides a lot of the same flexibility as delegates without the runtime overhead. It also allows the developer to work with a much smaller implementation of their portion of the partial class that contains only the few partial methods that have been implemented.

Debugging Finalizers

Scott Dorman — Fri, 26 Oct 2007 02:24:24 GMT

For the last few years, I've tried to make more .NET developers aware of the IDisposable interface, the Dispose pattern, and the importance of having at least a basic understanding of how the Garbage Collector works. I have one article on The Code Project and various blog posts (see here, here, here, or here) that talk about these topics. I have also presented an advanced Memory Management presentation at various Code Camps.

In the November 2007 issue of MSDN Magazine, Stephen Toub presents a solution in .NET Matters that solves the problem of making sure that other developers using your custom type dispose of it properly. Stephen mentions that Visual Studio and FxCop can help with this by performing static analysis on the code. Rule CA2000 (Dispose objects before losing scope) checks to see if any local IDisposable objects are created and then not disposed of before all references to the object are out of scope.

This rule can only do so much. In an effort to help complete the solution, Stephen presents a method that will warn developers when your type is garbage collected without having been disposed by using a debugging finalizer.

This is a very unique way of using a finalizer because it will only be present in debug builds of your code, so it alleviates the runtime performance costs associated with having a finalizer. This is a very well thought out generic solution to a fairly common problem. I highly recommend checking it out and if you write custom types that implement IDisposable you should consider implementing this solution.

[Update, 22-Jan-2008: Updated the article link for Code Project.]

Release builds are not Debug builds

Scott Dorman — Thu, 25 Oct 2007 23:22:46 GMT

Scott Hanselman has an excellent post on his blog where he talks about the differences between release builds and debug builds. Just to reiterate what should be obvious, as Scott points out:

Release builds are optimized for speed and debug builds are optimized for, well, debug-ability. However, most of the optimizations in managed code are done by the JIT compiler rather than the language compiler.

If you want to know about some of the real difference between release and debug builds, including C# method inlining and runtime optimizations, you should definitely take a look at his post.

Catching (Handling) Exceptions in .NET

Scott Dorman — Wed, 26 Sep 2007 21:42:57 GMT

It seems there is a lot of confusion on how to properly catch exceptions in .NET, especially among newer developers. There are a lot of good references available on MSDN and on the web, but a lot of these are either very advanced or just hard to follow.

I'm not going to discuss the CLR exception classes and go into the internals of how the .NET runtime generates exceptions. I don't want to discount this information, as it is helpful to know, but it isn't essential to understanding how to properly handle exceptions.

The most important thing to understand when handling exceptions is the concept of the Try/Catch/Finally block. This is a special section of code that is designed to allow you to work with exceptions. (This is a bit of a simplification, but that's the general idea.) Almost any line of code can cause an exception, but most applications don't actually need to deal with these exceptions. You should only handle an exception if there is something meaningful you can do as a result.

There are three ways you can specify a Try/Catch/Finally block:

Try/Catch
Try/Finally
Try/Catch/Finally

In order to understand the differences, it is important to first understand what the different sections are responsible for.

The Try block contains sections of code that might throw an exception.
The Catch block contains the code that should run when an exception is encountered.
The Finally block contains code that should always run, even if an exception was encountered.

The syntax for a Try/Catch/Finally block looks like this:

   1: int[] array1={0,0};   2: int[] array2={0,0};   3:     4: try   5: {   6:     Array.Copy(array1,array2,-1);   7: }   8: catch (ArgumentOutOfRangeException e)   9: {  10:     Console.WriteLine("Error: {0}", e);  11: }  12: finally  13: {  14:     Console.WriteLine("This statement is always executed.");  15: }

The part that tends to cause problems is the Catch handlers.

When an exception occurs, each catch block in the calling stack is given the opportunity to handle it. The proper catch block is determined by matching the type of the exception to the type of exception specified in the catch block.

A catch handler that only catches System.Exception or System.SystemException is called a general catch handler and should be avoided whenever possible as it can hide run-time problems and complicate debugging.

Since all exceptions in .NET inherit from System.Exception, this type of catch block will always match for any exception. If you think of catch blocks being evaluated in a "top down" approach, the first catch block that matches will be the one used. This means that if you put a general catch block first, none of the other catch blocks will be evaluated.

   1: try   2: {   3:     //some operation that results in InvalidCastException   4: }   5: catch (InvalidCastException e)   6: {   7:     Console.WriteLine("Invalid cast occurred.");   8: }   9: catch (Exception e)  10: {  11:     Console.WriteLine("General catch handler.");  12: }

In the example above, the output would be "Invalid cast occurred." However, if the catch blocks were reversed, the output would be "General catch handler."

Another common mistake is to use an empty catch handler. This is a catch handler that doesn't specify any exceptions and just uses the Catch keyword and is a result of legacy programming habits from the .NET Framework 1.0 and 1.1 releases.

In the .NET Framework 1.0 and 1.1 releases, there were situations where unmanaged code would throw an exception that wasn't properly handled by the runtime. As a result, it wasn't wrapped in a System.Exception derived exception and couldn't be caught by anything other than an empty catch block. This issue was corrected in .NET 2.0 and now these exceptions are wrapped in a System.Runtime.CompilerServices.RuntimeWrappedException (which inherits from System.Exception), so there is no longer a need for this empty catch block.

It is also common for people to write catch blocks that do nothing more than log the error. While this is sometimes important, it can usually be done by the top level caller and does not need to performed for each and every function. The best way to look at this situation is that you should only catch an exception if you have meaningful cleanup work that needs to be done as a result of the exception (like closing files or database connections).

This leads to a problem known as "swallowing exceptions", and occurs when you catch an exception and either do nothing with it or don't allow it to pass up the chain. This can also lead to problems because you are effectively hiding the exception and not doing anything with it, which can lead to intermittent problems that will be very hard to track down.

While we're talking about exception swallowing, there is a similar problem known as "breaking the stack". I talk about this in detail in another post, but it boils down to the fact that when you rethrow an exception you should almost always use the "throw" syntax.

Finally, if you are using a class that implements the System.IDisposable interface you can make use of the using Statement (C#) to simplify the code you need to write. I talk more about the using statement in this post.