Exceptions do not in themselves work well for this approach, because they imply a single failure. With web operations that are frequently “batched” in the sense that validation does not or cannot happen except for when an entire form is submitted, you may have many errors. So you need a framework for collecting errors and supplying them to the UI in a list rather than a single failure. We have an exception that collects other exceptions and have our library calls declared to throw that; then the specific exceptions are documented too so they can be used in front-end code. The messages are given in a field-keyed, I18N-friendly format – (fieldId, “file.not.found”, filename, directory) – rather than plain precomposed strings.

The expectation should be that things you call may throw either a single exception, or a collection of exceptions. If you don’t know how to handle them, you let them flow past you (our exceptions are almost all unchecked). If you have more to add yourself, you make a new collection and add the previous stuff and your stuff to it. If you made a library call, expect that exceptional conditions may produce a list of failures and be ready to handle them.

The languages and libraries ought to be smart enough to encourage this kind of pattern of use. They’re not, and there doesn’t seem much of a standard for it, unfortunately.

http://blog.thinkrelevance.com/2008/4/23/refactoring-from-ceremony-to-essence