how to: handle exceptions, best practices

Question

need to implement a global error handling, so maybe you can help out with the following example...

i have this code:

public bool IsUserA         


        

Answer 1

Two golden rules:

1. Throw an exception if a method can't do what its name says it does.
2. Don't catch exceptions unless you know exactly what to do with them.

Remember that an exception indicates that something has gone wrong, and that particular something may not be what you think. (Out of memory, stack overflow, 3rd party service gone down, botched deployment resulting in missing assemblies, mis-configuration, security exceptions etc).

With very few exceptions, the only place you should see Pokemon exception handling is at the topmost level of your code, where the exception should be published somewhere. For example, in the Application_Error method in your global.asax file.

Here are some links for you that you may find helpful:

• If Your Method Can't Do What Its Name Promises It Can, Throw
• The two golden rules of exception handling
• Exception-Driven Development
• ELMAH - Error Logging Modules and Handlers for ASP.NET

Answer 2

You need to think about the contracts that the methods define. If a method can't fulfill its contract then you need an exception. Exceptions thrown within the method should be translated into exceptions that make sense from the point of view of the contract of the method.

In the first case, I would catch any exceptions that can be thrown by statement execution (e.g. database errors) and translate them into something like an AuthorisationException. Allowing the exception to propagate straight up doesn't make sense from the point of view of the methods contract. For instance it doesn't make sense to allow a database exception to escape from the method when the method is fulfilling the contract of whether the author is authorised.

Using this idea of the method as a contract allows you to make the right decisions. If a method contract is logging into the database, or some database manipulation, then it might well make sense to allow the exceptions to propagate.

Getting specific: Using the first example:

public bool IsUserAuthorizedToSignIn(string userEMailAddress, string userPassword)
    {
        try
        {
            // get MD5 hash for use in the LINQ query
            string passwordSaltedHash = this.PasswordSaltedHash(userEMailAddress, userPassword);

            // check for email / password / validity
            using (UserManagementDataContext context = new UserManagementDataContext())
            {
                var users = from u in context.Users
                        where u.UserEMailAdresses.Any(e => e.EMailAddress == userEMailAddress)
                            && u.UserPasswords.Any(p => p.PasswordSaltedHash == passwordSaltedHash)
                            && u.IsActive == true
                        select u;

                // true if user found
                return (users.Count() == 1) ? true : false;
            }
        }
        catch(ThisException e)
        {
            thrown new AuthorisationException("Problem1 occurred");
        }
        catch(ThatException e)
        {
            thrown new AuthorisationException("Problem2 occurred");
        }
        catch(OtherException e)
        {
            thrown new AuthorisationException("Problem3 occurred");
        }
    }

You might also like to set the inner exception on the AuthorisationException:

        catch(ThisException e)
        {
            thrown new AuthorisationException("Problem1 occurred", e);
        }

Then your client code can do this:

try
{
    if(User.IsUserAuthorizedToSignIn)
    {
        // Let the magic happen
    }
    else
    {
        // No rights
    }
}
catch(AuthorisationException e)
{
    // Let the user know there is something up with the system. 
}

You may decide that you don't want to catch the AuthorisationException at the immediate calling site since you can't notify the user. So you may let it propagate up to a level where you can do something with it.

Hope that helps!

Answer 3

Your library code or the code that is used by higher-layers in your application must always only throw exceptions and never worry about how to deal with them.

This is important because you may use this library at many places for different purposes.

In your application presentation layer, if you're consuming a library code and you're aware about the possible exceptions then do catch them with try/catch.

Since you're using asp.net I'd recommend to write a common page-base class and work some error handling mechanism in Page_Error event that catches all un-handled exceptions on the page.

Even beyond that you can use Application_Error even in global.asax to catch any un-handled exception in any part of the application, Modules, Handler, services, pages etc.

I'd strongly recommend to not make it a general practice to handle all exception in global Application_Error.