Handling Errors In DDD-Flavored ASP.Net MVC2 Web Application

Question

What are "best practices" concerning error handling in an ASP.NET MVC2 web app that is DDD designed? For example, let's take the most common aspect of a web app, the login:

• UserController: Obviously coordinates a few domain objects to eventually log in or refuse the user, and redirect to other parts of the web interface as needed. In my case, it's a few calls to different UserTasks methods like IsLoggedIn() or LogIn(), plus some RedirectToAction.
• UserTasks: Has the meat of the work of coordinating relevant domain objects services, like SecurityService and lower domain objects, such as calling SecurityService.ValidateUser() or checking User.IsUserInactive().
• SecurityService: Obviously coordinates authentication/authorization services. Similar to a MembershipProvider, without the excess baggage.
• User: Represents the user. Not anemic, as it has various User-specific methods such as IsuUserInactive() that checks IsDeleted, IsLockedOut or if the user is between FromDt and ThruDt.

How do you bubble up errors such that they are informative and not hostile to users? Do you litter code with exceptions and then just handle them all in Application_Error()? For example, should ValidateUser() throw an ArgumentNullException() when password is empty and a AuthenticationException() when the password isn't right, or return a bool = false? If the latter, how do you inform the user of what caused the validation to fail?

Answer 1

I'm assuming you're using WhoCanHelpMe / S#arp Architecture based on the naming conventions I see? If so, I'd highly recommend a look at this article which demostrates the implementation of a cleaner application services layer. Have a look at the ActionConfirmation result being returned from the service layer; we have found this an ideal way to return a less-than-nasty error result from the Tasks layer.