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.