Matthias Noback has a new post to his site with some suggestions about exception handling and user feedback for both the backend experience and UI side.

Designing domain objects is all about offering meaningful behavior and insights through a carefully designed API. [...] So exceptions in your (object-oriented) domain model are not merely meant to signal an exceptional situation. They can be used to prevent invalid or unsupported usage of an object. By offering well-named methods (with sensible parameters) for changing the object's state, and by being very precise about throwing exceptions when invalid use is imminent, you make your domain objects usable in only one way: the way that makes sense. This is the exact opposite of how your domain objects end up looking if you generate getters and setters for every attribute.

He starts by looking at the use of exceptions to help with validation and a few ways they could be used:

• Exceptions get thrown ad hoc, whenever something threatens the consistency of the domain object.
• They often signal that something is about to happen that can't logically happen, like a state change that isn't allowed or conceptually possible.
• Exception messages may contain more information than you'd like to share with the user.
• Validation errors often require internationalization (i18n).

He explains each option and, where it helps, provides code examples to illustrate. He then moves on to the frontend, talking about changes to the UI when exceptions are thrown and some things on his "wish list" for frontend exception handling.