Thanks for this simple but powerful pattern. I’ve integrated it in our in-house development framework, with some WebFlow support in the form of an ExceptionHandler. When a Business Exception is thrown, the ExceptionHandler catches it and puts an error message in the SWF MessageContext, which is then displayed on screen using the JSF
tag. Other exceptions are not caught and result in a default error page, which is fine, since these are usually the result of a programming error. Perhaps an extra SystemException class could be added for exceptions that are not BusinessExceptions but also not the result of a programming error, for example when the network is down, or the database is unavailable. These should also result in a nice error message for the user, with the possibility to try again later.

The whole point of this setup is to NOT make the view layer aware for each and every new exception that might pop up.

However your point does have merit. I’m thinking in the lines of creating a utility/aspect that will translate all the different exceptions into an generic business exception that can be shown in the view layer. That way the service layer can throw individual different exceptions, the utility class knows how to show these on the screen and can use the context to build the appropriate exception. The controller then recieves a generic exception, with all the information. He does not need to know what particular subclass was thrown.

Sometimes the exception message is more than just an argument substitute construct. The message is possibly calculated from the number and type of the arguments, and a the responsibility of the presentation logic only.

Therefor I rather create a GenericBusinessException, or even better: GenericDomainException and – if appropriate – start subclassing from these. Why ? Because otherwise (using a key + arguments) presentation logic starts creeping into the service or domain level. Let me explain.

The sub-classed GenericDomainException is a full fledged domain object, with its own interface which exposes the context of the exception.
This domain exception is used in a presentation in the presentation layer, which retrieves the context from the exception and links it with some presentation logic.

Maybe I should clarify with some code. But it ’s sunday, and I’m well off bounds already here.

You have a good point there. It would be possible to expand the BusinessException with some list of arguments to be inserted into the translated key.
Most messageSource implementations can substitute stuff like {0} with an argument list.

1. Presumably the code property is used to look up a matching key to a user message, in something like an ApplicationResources.properties file?

2. Assuming the 1st approach is used, how would you present more informative error messages to the user, where parts of the message consists of dynamically substituted business values e.g. “Your current balance is x, which is too low to purchase the item request” – where x is the customer’s account balance?