Guidelines for consistent exception handling


Exception handling is an essential concept in object oriented programming. It permits us to indicate program or method failure in way that it does not affect the method signature and thus, not affecting the overall design of our methods and classes.

However, exception handling is maybe the most misunderstood part of OOP as far as I have seen. Some think that exceptions are an evil we must live with; an evil that oblige us to decorate our code with a ‘Try/catch’ block whenever we think that an exception may arose. I do think though that exceptions, when used appropriately, can be our ally in making our code more robust and error proof. Exception handling is also a major part of an application design and we should give it the necessary thinking time that it deserves.

In the following article, I hopefully try to put some light on good practices in throwing, catching and designing methods to deal with exceptions.

What is considered an execution failure?

Often, we wrongly consider that we should throw an exception only at exceptional circumstances. The rule actually is “If the method does not what its names suggests (aka what it is supposed to do), it should throw an exception to notify it” (1). A good example is the .NET framework : if you try to open a file for writing but the file is a readonly file, the method will throw an exception because it could not open the file as the method name suggests it. That is said, it is not an unhandled case in terms of the code of the Open method, but it is not a normal execution path neither.

Exception handling versus returning error codes

This is probably a wide topic but I am going to give the main reasons why we should not use error codes instead or even in conjunction with exceptions (by using an error code to identify the nature of the exception).

  • When using error code, we must usually find a way to also return whatever the method is supposed to return. That either makes us change the signature and use (out) parameters or (worse) embed the error code and the returned type into another class/structure.
  • Another reason, and probably most important one, is that whenever we call a method that returns an error code, we must test it otherwise, we may let the code execute in an unstable state and eventually, propagate the error to upper layers of the application. On the other hand, if we throw an exception, it should be either explicitly caught or the application will simply terminate. This makes the code more robust since even if we forget to catch an exception, we will notice it while testing which is not the case if we use error codes and forget to check returned codes.
  • An exception contains much more information than an error code. It contains the exact location of the encountered issue and it should contain, in the message, the exact reason of failure and, for well designed exceptions, how to fix the problem. We no longer need to document each error code and manage error codes duplications. The exception contains all the information developers need to know.
  • If we want an error to propagate to upper callers in the stack, we just let the exception unhandled and it will be propagated to upper layers. Whereas using codes, we must test for the code, return it and do this for all the callers of the method at all levels.
  • Exceptions can be instrumented and monitored using standard applications in Windows.
  • When debugging, we can set the debugger to start when a certain type of exception is thrown.

Sometimes we see developers returning an exception instead of an error code (return an exception type as the return parameter of a method and not throwing an exception) as in the following code.

     public InvalidPayDateException CalculatePayAmount(out double pay) {}

Actually, this type of error handling defeats most of exceptions’ benefits that we just have seen. Thus, it is better not to return exceptions instead of error codes. That is pretty much the same thing as returning a simple code.

 

Throwing exceptions

As mentioned before, an exception should be thrown whenever the method can not complete its execution normally even if the scenario could be predictable in some way. Opening a file that does not exist should raise an exception for example even though we probably are testing for the existence of the file before opening it. Throwing an exception is like saying ‘Everybody above! There is an issue here and I cannot continue to execute normally!’ and this message will go up until someone (code) knows what to do about it to stabilize the code and continue.

A good place to raise exceptions is in the method pre conditions. Pre conditions are a set of tests on the passed parameters (or execution context) to ensure that all parameters are valid and we can continue to execute the method.  If we look at the following code, chances are that the method is called with an employee object set to null which will cause an exception thrown by the CLR.

    public class PayManager
    {
        public double CalculatePayAmount(Employee employee)
        {
            double payAmount = 0;
            if (employee.PayMode == PayMode.BiWeekly &&
                employee.LastPaid > DateTime.Now.AddDays(-14))
                throw new InvalidPayDateException("This employee is not supposed to be paid this week");
        
            payAmount = 2000; // of course, not everyone is paid 2000$
            return payAmount;
        }
    }

Now the same method with pre-conditions will throw an exception with more details (customized details that could contain much more information for developers).

     public class PayManager
    {
        public double CalculatePayAmount(Employee employee)
        {
            if (employee == null)
                throw new ArgumentNullException("The employee object must never be null");
            double payAmount = 0;
            if (employee.PayMode == PayMode.BiWeekly &&
                employee.LastPaid > DateTime.Now.AddDays(-14))
                throw new InvalidPayDateException("This employee is not supposed to be paid this week");
           
            payAmount = 2000; // of course, not everyone is paid 2000$

            return payAmount;
        }
    }

Of course, this is only valid for things we can check before the method does what it should do. In the core of the method, we may need to throw exceptions as well and it is very important to pick up the right exception type to throw being it an existing type or a custom type we create for the purpose of the application.

Choosing the right type to throw

One way to choose the right type of exception to throw is to use the caller perspective. In other words, we need to answer the question  “what type of information should the caller know in order to be able to do something if it catches the exception?”.

For instance, a method can throw several custom exceptions to indicate different issues and, on the caller side, even though these exceptions will be caught separatly (each type has its own catch statement), the treatment will be exactly the same. In such scenario, we will end up with a lot of code duplication as shown in the following code.

        public void DoSomething()
        {
            try
            {
                callMethod();
            }
            catch(customOneException ex)
            {
                log(ex);
                RollBackTransaction();
            }
            catch(customTwoException ex)
            {
                log(ex);
                RollBackTransaction();
            }
            catch(customThreeException ex)
            {
                log(ex);
                RollBackTransaction();
            }
        }

If we have considered the caller in our ‘doThisThing()’ method design, we would have thrown only one type of exception instead of the three and the caller code would be cleaner. This is not always possible, however we should always keep in mind how the caller will catch and treat different exceptions we may throw.

Creating custom Exceptions

I like a definition I have read in the ‘Framework Design Guidelines’ book: “Do not create an exception type if it can not be handled differently from existing .NET framework exceptions’. That makes the focus on how the exception is caught and not only on the nature of the exception as we may tend to do usually. In other words, if there is no added value for the caller in having a new exception type, do not create one and use standard exception types instead.

There are many “generic” exception types that can be used in different scenarios:

  • ArgumentInvalidException, ArgumentNullException and ArgumentOutOfRangeException
  • InvalidOperationException

If we consider these exceptions, we figure out that they may cover many cases of invalid arguments or, for the latest, an operation that we attempt to execute on an object in an invalid state for instance.

There are other exceptions that we should avoid using such as those thrown by the CLR (OutOfMemoryException, StackOverflowException and alike). Only the CLR should be able to throw these types. Another particular case is the System.Exception: this exception should not be thrown because it does not tell anything about the encountered issue. Remember that the type of the exception is actually the first indication of what caused it and using one custom type for the whole application is as inefficient as using the System.Exception base class.

Performance considerations

We must be careful not to have very common scenarios that provoque too many exceptions which will impact the performance. In such case, we should use one of the following two patterns:

Tester-Doer Pattern

Let’s say we do have a pay calculator that calculates the pay amount for an employee. To make things a bit more complicated, let’s consider that we do have weekly and bi-weekly paid employees. The PayManager may throw an exception in the case we try to calculate a pay for an employee that is not supposed to be paid that day.

Now, if we look at the following code:

    public enum PayMode
    {
        Weekly,
        BiWeekly
    }

    public class Employee
    {
        public DateTime LastPaid
        {
            get;
            set;
        }

        public PayMode PayMode
        {
            get;
            set;
        }
    }
   
    public class InvalidPayDateException : Exception
    {
        public InvalidPayDateException() : base() { }
        public InvalidPayDateException(string message) : base(message) { }
    }

    public class PayManager
    {
        public double CalculatePayAmount(Employee employee)
        {
            double payAmount = 0;
            if (employee.PayMode == PayMode.BiWeekly &&
                employee.LastPaid > DateTime.Now.AddDays(-14))
                throw new InvalidPayDateException("This employee is not supposed to be paid this week");
           
            payAmount = 2000; // of course, not everyone is paid 2000$

            return payAmount;

        }       
       
        public void CalculateEmployeesPay(ICollection<Employee> employees)
        {
            foreach(var employee in employees)
            {
                try
                {
                    var pay = CalculatePayAmount(employee);
                    //do something with the pay.
                }
                catch(InvalidPayDateException)
                {
                    //Do something
                }
            }
        }
    }

The first thing we notice is that every two weeks, there will be a number of cases where the InvalidPayDateException will be thrown because many employees should only be paid on a bi-weekly basis. This may have an impact on the performance and since it is a predictable scenario, we certainly should do something to avoid it.

One solution would be adding a method ‘IsValidPayDay(Employee)’ which will indicate whether or not the current date is valid for the current employee. Then, we will modify the method CalculateEmployeesPay in order to first check whether the current date is valid for the current employee and only in this case, do a pay calculation.


    ...
    public class PayManager
    {
        public double CalculatePayAmount(Employee employee)
        {
            double payAmount = 0;
            if (!IsValidPayDate(employee))
                throw new InvalidPayDateException("This employee is not supposed to be paid this week");
           
            payAmount = 2000; // of course, not everyone is paid 2000$

            return payAmount;
        }

        public void CalculateEmployeesPay(ICollection<Employee> employees)
        {
            foreach(var employee in employees)
            {
                if (IsValidPayDate(employee))
                {
                    var pay = CalculatePayAmount(employee);
                    //do something with the pay.
                }               
            }
        }
      
        public bool IsValidPayDate(Employee employee)
        {
            if (employee.PayMode == PayMode.BiWeekly &&
                employee.LastPaid > DateTime.Now.AddDays(-14))
                  return false;

            return true;
        }

   }

In this case, using the tester-doer pattern is legitimate and in fact, it may save us a number of unnecessary exceptions. However, there might be cases where the tester will be too expensive in itself; for instance a tester that will have to grab information from the database. Eventually, such tester will cost more than throwing exceptions and one way to avoid both, too many exceptions and an expensive tester, we should use the Try-Parse pattern.

Try-Parse Pattern

The Try Parse pattern consists in exposing a method and an exception safe version of the same method so that other programmers will be able to call it without paying attention to the exception. In .NET framework such pattern is used for the DateTime.Parse method. In fact, there is another version of this method called DateTime.TryParse which returns a boolean indicating whether the method succeeded or not and an OUT parameter that contains the resulting DateTime object in case it is successfull.

Generally speaking, when we use this pattern, we should provide both methods: with and without exceptions and both methods have the same name with a “Try” prefix for the exception safe one.

In our example, if we use the Try-Parse pattern, we add a TryCalculatePayAmount (same name with the Try as prefix) and as a result we will have the following code:

    public class PayManager
    {
        public double CalculatePayAmount(Employee employee)
        {
            double payAmount = 0;
            if (employee.PayMode == PayMode.BiWeekly &&
                employee.LastPaid > DateTime.Now.AddDays(-14)))
                throw new InvalidPayDateException("This employee is not supposed to be paid this week");

            payAmount = 2000; // of course, not everyone is paid 2000$

            return payAmount;
        }

        public bool TryCalculatePayAmount(Employee employee, out double pay)
        {
            bool result = true;
            try
            {
                pay = CalculatePayAmount(employee);
            }
            catch (InvalidPayDateException)
            {
                result = false;
            }

            return result;
        }

        public void CalculateEmployeesPay(ICollection<Employee> employees)
        {
            foreach (var employee in employees)
            {
                    double pay = 0;
                    if (TryCalculatePayAmount(employee, out pay))
                    {
                        //do something with the pay.
                    }
            }
        }
    }

Catching exceptions

Now, let’s talk about the other side of the exceptions. The catching. There are three main points to consider:

  • When do we catch an exception
  • What exceptions’ types should we catch
  • What should we consider when rethrowing and wrapping exceptions.

When do we catch?

We catch an exception only when we do something about it. The something about it can be anything like:

  • Solving the problem so that the program can continue to run.
  • Wrap the exception in another exception type to add more details about the context and rethrow it.
  • Stabilize the program and rethrow the same exception
  • Log the exception and continue as if nothing happened.

That is said, we should always avoid a Try-Catch-Finalize block with an empty Catch section. This will only hide potential issues. However, having a catch section that just rethrows the same exception can only be useful if the finalize section does something otherwise, we better remove the try-catch block at all.

What do we catch?

We should never catch the System.Exception exception (too generic) neither should we catch CLR exceptions (StackOverflowException, OutofMemoryException etc…). For the first, the reason is that catching the exception base type does not give us any information about what really happened. It is ‘blind’ catching which will hide all other sorts of exceptions (including CLR ones). For the second, the reason is pretty obvious: we cannot do anything to solve a stack overflow problem for example. In very rare circumstances, we may need to catch an OutofMemoryException but in most scenarios, we should not do it and let the exception go up.

The most precise in our catch statement we are, the more robust is our code because it will show us, in testing, what are the potential issues (exception types) that may arise from a particular method. If we ‘swalow’ all the exceptions, despite their type, we may feel that the code is robust but in reality, we’re just hiding real potential issues.

Rethrowing and wrapping

  • When rethrowing the same exception, we better use ‘throw’ (without arguments) otherwise, we will loose stack information.
  • When wrapping an exception, it might be a good idea to include the original exception as the inner exception (to keep some information about the original context).
  • Consider wrapping exceptions to give more details about the context. For instance, a caching component (that does file caching) may have a FileNotFoundException thrown when it tries to access a cache file. However, for its users, that might not have enough information to understand the exception. In this case, we should wrap it in a CacheFileNotFoundException (custom type) that contains information on the query we have done to the caching component for instance.

Conclusion

Exception handling is an important part of any software programming and it is very important to take the time to think about an approach before starting a new project. In this article I tried to go through the most important aspects we should take into consideration without going in too much details in some cases. For this reason I added the references below of two excellent books that, among other things, cover exception handling and programming rules in general.

References

  • (1) Framework Design Guidelines Second Edition (Conventions, Idioms, and Patterns for Reusable .NET Libraries) – Addison Wesley –
  • Clean Code (A Handbook of Agile Software Craftsmanship) – Prentice HALL –

Efficiently synchronize threads’ access to shared data


Accessing shared members, or static data, in an ASP.NET context must be done carefully. Actually, we must ensure that the code is thread-safe by using a synchronization mechanism. In other words, we must ensure that the static data is accessed by one thread at the same time only.

Usually, we achieve that using ‘lock’ keyword (C#). For instance, in an application we do have a cache manager class that stores some data in a memory cache shared by all the threads. If the cache manager has the data in its dictionary, it returns it otherwise; we will get it from the database and store it in the cache manager (this is for illustration only. Do not bother with the design).

The code would look like:

        public string RetrieveSingleContent(string key)
        {        
                string cacheValue = CacheManager.ReadFromCache(key);
                if (cacheValue != null)
                    return cacheValue;
                lock (_lockObjectSingleContent)
                {
                        using (IDataReader content = GetFromDB(key))
                        {
                            cacheValue = content.GetString(0);
                        }
                        CacheManager.AddToCache(key, cacheValue);
                }
               return cacheValue;
        }

What’s wrong with this code?

If we do have many threads requesting the same content (same key), we will end up with a queue of threads wanting to access the locked section of the code. Once we have retrieved the content from the database (first thread), the next thread will request the same data from the database even though the first thread did it already.

Checking the cacheValue before getting the database is not a solution either because cacheValue is a local variable and thus, it is not shared by all the threads. Therefore, the most efficient solution in the case is to query the content manager outside the lock section and also inside the lock section. In this case, whenever a queued thread will enter the section, it will first recheck whether the requested content has been retrieved in the meantime (between the moment it was waiting for its turn till it gets inside the locked section).

The new method will therefore look like:

        public override string RetrieveSingleContent(string key)
        {
                string cacheValue = CacheManager.ReadFromCache(key);
                if (cacheValue != null)
                    return cacheValue;
                lock (_lockObjectSingleContent)
                {
                    cacheValue = CacheManager.ReadFromCache(key);
                    if (cacheValue == null)
                    {
                        using (IDataReader content = GetFromDB(key))
                        {
                            cacheValue = content.GetString(0);
                        }
                        CacheManager.AddToCache(key, cacheValue);
                    }
                }
                return cacheValue;
        }

Obviously, if querying the cache manager for data is more expensing than getting the data from the database, then this will no longer be valid. But anyway, in this case, you should not use the cache at all.

Generics constraints


It has been a long time since the generics are around and most of developers are using them in their code. In this post, I would like to talk about how to use generics more effectively by using constraints.

 What are constraints?

Constraints are conditions applied on the parameter type that are checked at compile time.

Why constraints?

We use constraints to avoid runtime errors when we create generic types.

For instance, if we write a generic class that calculates an employee salary. We want this class to be generic because we may have different types of employee classes (this is for illustration only):

 

public class Employee
    {
        public string Name
        {
            get;
            set;
        }

        public doubleHourlyRate { get;
            set;
        }

        public double NumberOfWorkedHours
        {
            get;
            set;
        }
    }

    class PayCalculator<T>
    {
        public double CalculateEmployeeSalary(T employee)
        {
            //We need an employee from the T type
            Employeeemp = employee as Employee;
            returnemp.HourlyRate * emp.NumberOfWorkedHours; 
         } 
       }    

What’s wrong with this code?

At runtime, there is no guarantee that the type passed to PayCalculator is an Employee type. If it is not an Employee, the ’emp’ variable will have a null value which will make the last line of the CalculateEmployeeSalary method raise a null value exception. We can add a test to check whether or not the ’emp’ variable is null before we calculate the salary. This will fix a runtime error but still, a developer could instantiate our PayCalculator with a non valid type which will lead to an unexpected result.

To avoid this situation, we must add a constraint to our generic class. which will look like:

class PayCalculator<T> : where T:Employee
    {
        public double CalculateEmployeeSalary(T employee)
        {
            //We need an employee from the T type
            Employeeemp = employee as Employee;
            returnemp.HourlyRate * emp.NumberOfWorkedHours;
        }
    }

This means that whenever we instantiate a PayCalculator with a type, the compiler will check whether the passed type is an Employee type or not (actually, it can be a derivative of Employee). If it is not the case, it won’t compile at all.

Types of constraints:

There are 6 types of constraints:

  1. where T : <base class> this is the one we just have seen.
  2. where T: <interface> the type must implement a certain interface.
  3. where T: new() the type must have a parmeterless constructor
  4. where T: U in this case our generic has two parameters and the T one must inherit from type U.
  5. where T: struct T must be a value type
  6. where T:class T must be a reference type.

Note that constraints can be combined: you can have more than one constraints for a class. In this case, the ‘struct’ and ‘class’ constraints (respectively 5 and 6) must be the first constraints. The ‘new()’ constraint, on the other hand,  is always the last one to be specified.

You can find more details on MSDN: http://msdn.microsoft.com/en-us/library/d5x73970(VS.80).aspx

There is also good examples in the book “More effective C#”

 

ASP.NET AJAX Collapsible form section


There are many cases where we may need to implement complex forms that contain multiple sections that can be hidden or shown depending on the user’s entries. The issue we encounter in such scenarios is that the section we want to hide or show may contain validators that must be disabled in order to let the form to post back. This can be easily achieved using a server side code, but it involves a round trip to the server which we would like to avoid for performance reasons.

I have written a generic AJAX enabled control that will help you, very easily, to hide or show a form section with client side code (Javascript) so that you no longer have to worry about all the plumbing in JS that manages validators.

You can find the article that describes the solution along with the source code on the following link: http://www.codeproject.com/KB/ajax/AJAX_Collapsible_form.aspx

Combining javascript files with Ajax toolkit library


One of the new features that came with .NET Framework SP1 is the ability to combine multiple js files in order to reduce the number of files downloaded by the browser.

In theory, you simply have to list all the JS files called by the page in a sub section of the script manager. You can get the list of files needed by your page by using the script reference profiler (third party control that lists all the files). You can find this control on http://weblogs.asp.net/bleroy/archive/2008/06/12/script-reference-profiler.aspx

Once the list is known, you just need to copy/paste it in the Script Manager control using the new ‘CompositeScript’ tag. This is an example from a real world application using Telerik and AJAX toolkit controls.

 <asp:ScriptManager ID=”ScriptManager1″ runat=”server”>
<CompositeScript ScriptMode=”Release”>
<Scripts>
<asp:ScriptReference name=”MicrosoftAjax.js”/>
<asp:ScriptReference name=”MicrosoftAjaxWebForms.js”/>
<asp:ScriptReference name=”AjaxControlToolkit.Common.Common.js” assembly=”AjaxControlToolkit, Version=3.0.20229.17016, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e”/>
<asp:ScriptReference name=”AjaxControlToolkit.ExtenderBase.BaseScripts.js” assembly=”AjaxControlToolkit, Version=3.0.20229.17016, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e”/>
<asp:ScriptReference name=”Telerik.Web.UI.Common.Core.js” assembly=”Telerik.Web.UI, Version=2008.2.826.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4″/>
<asp:ScriptReference name=”Telerik.Web.UI.Common.Animation.AnimationScripts.js” assembly=”Telerik.Web.UI, Version=2008.2.826.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4″/>
<asp:ScriptReference name=”Telerik.Web.UI.Common.Scrolling.ScrollingScripts.js” assembly=”Telerik.Web.UI, Version=2008.2.826.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4″/>
<asp:ScriptReference name=”Telerik.Web.UI.Common.Navigation.NavigationScripts.js” assembly=”Telerik.Web.UI, Version=2008.2.826.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4″/>
<asp:ScriptReference name=”Telerik.Web.UI.Menu.RadMenuScripts.js” assembly=”Telerik.Web.UI, Version=2008.2.826.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4″/>
<asp:ScriptReference name=”Telerik.Web.UI.ComboBox.RadComboBoxScripts.js” assembly=”Telerik.Web.UI, Version=2008.2.826.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4″/>
<asp:ScriptReference name=”Telerik.Web.UI.TabStrip.RadTabStripScripts.js” assembly=”Telerik.Web.UI, Version=2008.2.826.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4″/>
</Scripts>
</CompositeScript>
</asp:ScriptManager>

Note that you can add references to your own JS files using the path to the Javascript:

i.e: <asp:ScriptReference Path=”~/js/MyJavascript.js” />

 However, this example won’t work properly. As you try to run a page that contains it, you will get the following error message:

The resource URL cannot be longer than 1024 characters. If using a CompositeScriptReference, reduce the number of ScriptReferences it contains, or combine them into a single static file and set the Path property to the location of it.

To fix this issue, you should split the list into smaller chuncks and add them in different Proxy Script Manager controls. Bear in mind that each of these controls will generate a separate JS file and therefore you may end up with as many JS files as the number of Script Manager/Proxy Script Manager controls.

<asp:ScriptManagerProxy ID=”ScriptManagerProxy1″ runat=”server”>
<CompositeScript ScriptMode=”Release”>
<Scripts>

…. SCRIPT References….(subset)
</Scripts>
</CompositeScript>
</asp:ScriptManagerProxy >

<asp:ScriptManagerProxy ID=”ScriptManagerProxy2″ runat=”server”>
<CompositeScript ScriptMode=”Release”>
<Scripts>

…. SCRIPT References….(another subset)
</Scripts>
</CompositeScript>
</asp:ScriptManagerProxy >

Another issue you should pay attention to is the order of your custom JS files. If you have any of your files that has Javascript code that executes at load (not in a function) and in which you use some Ajax functionality, ensure that you download it after the Ajax files. In other words, ensure that all Ajax library JS files are referenced before yours. I suggest that you put all your files in a separate Proxy Script Manager to isolate them and put this section as the last one in the list.

By combining files you create a new file with a URL that contains the references of all the JS included in the new resource (that’s the reason why it is limitted to 1024 characters in the URL). That’s said, you better have always the same sections with the same files in the same order so that the browser will download them only once and cache them for future use. I think that it is better to download a larger file than needed rather than redownloading many times the needed part only.

My suggestion is to put all references to common Ajax library files in multiple sections of the script manager and subsequent proxy script managers and put all this list in a/multiple user controls that you’ll add to your pages. Custom scripts should be added separately as needed or listed in one Proxy Script Manager and shared across all pages if you don’t have that many files.

As it is highly recommended to load javascripts at the end of the page, I suggest that you keep your ScriptManager empty of any JS reference and put all your references in ScriptManagerProxy controls placed at the end of the page.

C# 3.0 Extension Methods


One of the new features in .NET 3.5 and C# 3.0 is extension methods. Extension methods, as their names state, let you extend any existing type by adding new methods without having to inherit from it.

For instance, one of the common issues we encounter when retrieving data from the database, is to check whether the value is DBNULL or not before we can use it. I used to write a DbReaderHelper class that actually implements ‘dbnull safe’ data retrieval methods. The syntax to declare an extension method is very simple. It is a static method which its first argument starts with the keyword “this” followed by the type we want to extend.

For instance, if I want to add a new method called “nGetInt32” which returns an Int32.MinValue if the field is dbnull otherwise the field value (an Int32), I should write it as follows:

 

public static Int32 nGetInt32(this DbDataReader reader, int index)
{
      if (reader.IsDBNull(index))         
         
return Int32.MinValue;
      
     
return reader.GetInt32(index);
}

How to use it?

The extension must be part of a static class (see the example at the end of this post). To use it, simply add the namespace the class belongs to as part of the “using” directives and that’s it. Even intellisense will take it into account;

extension-method.png

 

Why using extension methods

If we want to extend the DataReader class to make it dbnull safe, we would have to inherit from one of its implementations and therefore would not be able to extend all inherited classes. The other advantage is the fact that you can extend any class (even those marked as “sealed”. On the other hand, extending a class has a limitation which is that the extension method can only use public methods and therefore there’s no access to the inner state of the object. 

Methods resolution 

          Instance methods have priority
          If the same extension method is declared more than once, the compiler raises an error.
          The compiler looks into the current namespace and all the namespaces included with the using directive. 

 

C# 3.0 Anonymous types


With C# 3.0 you can declare a variable without typing it explicitly and its type will be inferred based on the right expression. This is different from the non typing in VB like languages (ASP, VB) as the resulting value is really typed and can no longer be assigned to a different type. Also, right after entering the line that declares the variable, intellisense becomes available.

Intellisense

We can see that actually the variable x is of an anonymous type with the two properties Name and EmployeeNumber plus the inherited properties from the Object class. If we declare another anonymous type variable with the same structure: 

var y = new { Name = “Smith”, EmployeeNumber = “199283” }; 

Then the new variable, y, is compatible with x. In another words, since it has the same properties with the same types (string, string) then C# compiler detects that x and y are of the same type even though we never declared it explicitly. In this case the instruction: x  = y is correct and will result in affecting the value of y in x. However if we declare a third variable z:   

var z = new { Name = “Buddy”, Company = “Microsoft” }; 

and try to affect the value of z to x for instance, we will have a compilation error (and not a runtime error – typical for non-typed variables – ). Even though z has two members of string type, all like x and y, it is not compatible. The reason is that the second property has not the same name (company versus EmployeeNumber). 

Some restrictions to anonymous types:

Anonymous types are only permitted for local variables. You cannot declare a class member with the var keyword. A method cannot return a var type neither can it has a var type parameter; all the following declarations won’t compile: 

public int function(var x, int y)
public var function(int x, int y)

however returning a var variable value is permitted:  

public int function(int x, int y)       
{
           
  var t = x + y;
           
     return t;       
}

The reason is simple : at the point of the ‘return’ statement, the compiler knows that ‘t’ is an integer and can be returned since the method must return an integer. 

Why using anonymous types?

First, let’s calm down the spirits who think that this is a step back to untyped variables. As mentioned in this post, it is really an implicit typing and if you look at it closely, the variables are typed but the type is constructed ‘on the fly’ if we want. We can use it without declaring it. 

This may open the door to poor programming if it is overused. However, the impact might be limited since the anonymous type has only the scope of the method where it is used.  The main advantage of the anonymous types is in LINQ (beyond the scope of this post). I will post something on LINQ pretty quickly… 

Well the only advantage I can see is to be able to manipulate temporary results in a collection of an anonymous structure and then do something with it without having to declare a very lightweight structure or class just to carry the results in one single method. I can see the usage in a data access layer class that has to process the result returned by a DataReader. But until today, we lived without it and never felt really a need for it. 

As a conclusion, I believe that the real advantage is the LINQ query…. Which I will talk about in my next post.