N-Layer/N-Tier error handling design

Question

Out team is building an N-Tier application that will handle a lot of database and network methods.

Basically we designed the following layers (from bottom to up):

Data layer: Can be Oracle or SQL (basically an EF entity and context auto-generated using Database First) Persistent layer: Handle the Data tier. We have a persistent tier for Oracle and another for SQL with some small changes between them (we would like to refactory that in future to have a single code - ideas accepted). Business layer: This is handling specific application logic.

Above that we can have a presentation layers (ASP.NET App), an API that calls directly business functions, a network agent that will allow business requests from network and so on.

We are having doubts regarding the error handling mechanism. We decided that all exceptions are threated on business layers, so this is the only place where I have try/catch statements.

Our point is we don´t want the app users to get rid of exceptions, but they need to know the status of operations. We created a ReturnStatus class that looks like:

public class ReturnStatus
{
    public enum ReturnStatusTypes : int { Success, Failure, Unknown }

    public ReturnStatusTypes Status;
    public int MessageCode;
    public string Message;

    /// <summary>
    /// Class constructor
    /// </summary>
    public ReturnStatus()
    {
        Status = ReturnStatusTypes.Unknown;
        MessageCode = 0;
        Message = "";
    }

    /// <summary>
    /// Class constructor
    /// </summary>
    /// <param name="status">Status</param>
    /// <param name="message">Message</param>
    public ReturnStatus(ReturnStatusTypes status, int msgCode)
    {
        Status = status;
        MessageCode = msgCode;
        Message = ErrorMessages.ResourceManager.GetString("ErrorCode" + msgCode);
    }
}

The Message property is localizable depending on the App culture set before.

We would like that every call to a Business layer method has a ReturnStatus. That can be logged into ASP.NET status bar, returned to the API or sent over network to the other apps. The prob is that most of our business classes returns data, so we need to find a way to return status and data together to the consuming actors.

Our staff is considering: a) Using tuples on every call. That seens not to be the recommended way. b) Throw an expection: not compliant with our architecture. c) Using out ReturnStatus on every call: Considered an option, even looking old fashioned. d) Keeping a last error object somewhere, so the call can return data directly and user may call lastactionstatus to get this error. Our point is: we don´t know where to store that last error data. On a singleton class ?

The solution must be uniform between all business methods.

What would you recomend for the best method and how to implement it.

Answer 1

You are doing something wrong, but look at this info i get it from Microsoft Enterprise library

Using Exception Handlers The Exception Handling Application Block is designed to support the typical code contained in catch statements in application components. Instead of repeating this code (such as logging exception information) throughout identical catch blocks in an application component, the application block allows developers to encapsulate this logic as reusable exception handlers. Exception handlers are .NET classes that encapsulate exception handling logic and implement the Exception Handling Application Block interface named IExceptionHandler. The Exception Handling Application Block includes four exception handlers:

Wrap handler. This exception handler wraps one exception around another.

Replace handler. This exception handler replaces one exception with another.

Logging handler. This exception handler formats exception information, such as the message and the stack trace. Then the logging handler gives this information to the Enterprise Library Logging Application Block so that it can be published.

Fault Contract Exception Handler. This exception handler is designed for use at Windows Communication Foundation (WCF) service boundaries, and generates a new Fault Contract from the exception.

Very important, the main thread must catch all exception also if you have another process, for example read from device and make the localization of the error message in main thread(UI).

I recommended you to use Microsft Enterprise library.

Exception Handling in MEL 6.0

Answer 2

Here you can review some guidelines for exception throwing, also some performance concerns to take into consideration.

I have been using Elmah to log exception, for some time now, and I totally recommend it.

Exception handling with Elmah can give you a hint, how you can use it.

Hope it helps!