handling unhandled asp.net exceptions

At some point in their career everyone who creates ASP.NET applications has had issues with their site throwing exceptions that aren’t trapped.  We end up displaying a friendly error page at best, and at worst display the yellow ASP.NET error screen of death.  Generally speaking it’s best practice to configure your ASP.NET application to use friendly error pages so that your users aren’t presented with an exception and stack trace that are meaningless to them.

But how do you find out what exceptions are being thrown by users who are not you?  Over the years I’ve created many versions of the same type of code to handle these situations, so last night I created a project on codeplex that I’m calling sigh.net.  Essentially, sigh.net is a provider based unhandled exception handler for ASP.NET applications.  You can download the source at http://www.codeplex.com/sigh.

It’s extremely simple to use and doesn’t require you to change or add any code to your application.  I currently have an email provider created and am in the process of creating a SQL database provider.

Enjoy!

system.nullable vs. tryparse : revisited

As a followup to my system.nullable vs. tryparse entry, I’ve decided to publish the nullable parser code that I use in the data access system of .netSavant.

Download the C# file (in txt format)

Enjoy!

visual studio.net 2008 extension methods

Now that visual studio.net 2008 has been released developers have a much improved development environment and framework to produce high quality code with.  Extension methods are one of the new framework and IDE features that provides a powerful and clever method of extending objects that you do not have source code for or otherwise can’t directly extend.

Simply put, extension methods allow you to add new methods to the public contract of an existing type without sub-classing, decorating or recompiling the original type.  Prior to this release there were a few options available to solve this problem.

nullable types and ado.net parameters

As most people are aware the .NET 2.0 framework supports nullable value types.  There are many articles on this topic and a few that address the issues of using nullable types in combination with your ado.net code.  However, most of these discuss the issue of using nullable types in combination with the DbDataReader objects, though few address the conflicts that arise when using a nullable type to set or get an ado.net parameter value.

Prior to .net 2.0 you’d run into this issue when attempting to pass a null string to the value of an input parameter.  In this case most of us would have written conditional code that looked something like this:

string firstName = null;
if(firstName == null) {
    Command.Parameters["FirstName"].Value = DBNull.Value;
} else {
    Command.Parameters["FirstName"].Value = firstName;
} 

Or you could have used a ternary operation: 

string firstName = null;
Command.Parameters["FirstName"].Value = firstName == null ? (object)DBNull.Value : firstName;

system.nullable vs. tryparse

I’ve been working on some code tonight and needed to use the trusty struct.TryParse methods available in the core framework.  Unfortunately, the built in TryParse methods choke on nullable types.  After a frightfully short google search I ran across a blog entry from Steve Michelotti describing his approach to writing his own TryParse object for nullable types.  Its pretty sweet though it didn’t meet a specific need that I had, specifically the ability to have the result parameter have its value set to null in cases where the string passed in is in fact null (or empty).

I’ve modified his basic concept with an overloaded method that allows you to specify how the result parameter value will be set.  Passing true to the alwaysNull parameter will always set your value to null if the string sent to the function is null or empty (which is what I’m using for my code problem).  Conversely, passing false will result in the default behavior expected from the TryParse methods.

public static class NullableParser {
    private delegate bool TryParseDelegate(string s, out T result) where T : struct;
    private static bool TryParseNullable(string value, out Nullable result, TryParseDelegate tryParse, bool alwaysNull) where T : struct {
        if(string.IsNullOrEmpty(value)) {
            if(alwaysNull) {
                result = null;
                return false;
            } else {
                result = default(T);
                return false;
            }
        }
        T tempResult;
        bool success = tryParse(value, out tempResult);
        result = tempResult;
        return success;
    }

    public static bool TryParse(string value, out DateTime? result, bool alwaysNull) {
        return TryParseNullable(value, out result, DateTime.TryParse, alwaysNull);
    }
    public static bool TryParse(string value, out DateTime? result) {
        return NullableParser.TryParse(value, out result, false);
    }
} 

Clearly this needs to have the rest of the native value type methods completed, i.e. TryParseInt, TryParseDouble, TryParseBoolean, etc. though it illustrates the basic concept well.

Enjoy!