How to properly define exception strategy in .NET enterprise application with DDD pattern?

Question

I am developing enterprise-like project by using DDD pattern. I have following projects in my C# solution:

• Domain model - DLL project

• WebUI - ASP.NET MVC3 project

• DesktopUI - WPF project

• DAL - Entity Framework Code First

• Persistance - SQL Server Database

This project is not large but I am trying to use all good practices of enterprise applications.

What I'd like to define now is exception strategy but I am not sure how to approach that. I should probably use Enterprise Library Exception Handling and Logging Blocks but I am not sure how to fit that into the picture. Some concrete scenarios I am trying to resolve in my head are following:

• If new Entity is created by the user in the WPF application, and Save button is clicked how should error be reported and logged in case an exception occurs at different levels (eg. entity is not properly created according to domain rules, or there was an error trying to persist new object to database)

• User tries to retrieve unknown entity from database (eg. from WebUI by specifying unknown entity Id in URL)

I understand I can define custom exceptions but I am not quite sure where and how. Should they be defined per each layer? I know there is wrapping exception practice but again not quite sure how to best use that pattern.

Also should I create one custom exception for each error in some layer (eg. UserAlreadyExistInDatabaseException for trying to save two users with same email, and UnknownUserDatabaseException if trying to get unknown user from DB) or should I have one exception type that handles multiple layer errors (eg. DatabaseException, and then differentiate errors with custom property or Exception.Message property).

Answer 1

I would stay away from the EntLib exception handling and logging blocks because they are just too complex to configure and deal with in general. You can certainly explore them to see how these types of problems can be approached, but it is often easier to roll your own solution or use something like log4net or NLog for logging.

As far as handling exceptions, the presentation layer (WPF or ASP.NET) should catch and interpret exceptions raised by the application service layer. The application service encapsulates your domain including the domain model and the data access layer (repositories in DDD speak). The application service can either return result objects which can contain error information or propagate exceptions from the domain or DAL.

You should create custom exception types if you intend to catch them in order to do something specific with a given exception type. An exception such as UserAlreadyExistInDatabaseException can be helpful because the application service can catch it and return some sort of result object to be interpreted by presentation layer, or the exception can be caught in the presentation layer which would in turn inform the user.

Logging can be done at the application service layer or the presentation layer or both. For example, an application service can catch an exception from the DAL, log it, and wrap it in another exception that the presentation layer can interpret.

User tries to retrieve unknown entity from database

This can be handled in several ways. One way is that the app service returns a null reference, and the presentation layer returns an appropriate message to the user. Alternatively, the DAL can raise something like EntityNotFoundException which can be caught at the presentation layer, also returning an appropriate message to the user. Raising such an exception can be beneficial with something like ASP.NET MVC because you can create an action filter which returns a generic response upon receiving an exception of said type.