The exception one is near-and-dear to my heart at the moment, as we're in
the process of refactoring a large app that currently does various checks
in the UI layer so it can present nice errors, when it should really be
leaving those checks to the business logic layer and then throwing app
specific exceptions that the UI layer understands and can present to the
users.

As Raymond noted, I think we need to be very cautious when it comes to
exception handling, especially with Go advocates propagating all sorts of
foolishness about the evils of exceptions and the notion that return codes
are somehow now a superior approach :P

However, I'm not sure we have a guideline about using deterministic
resource management to better cope with unexpected exceptions - I'll look
into that.