Exception handling in layered architecture

Question

We are Refactoring (and of-course redesigning) our Services in layered design. We have Service operations layer (BLL), Network abstraction layer -> (deals with network proxy), Data abstraction layer. But we are a bit baffled about our exception handling strategy.

1. We don't want to expose too much information from BLL to outside world. (from other layers to bll is fine)
2. We don't want to clutter the code with try catch stacks
3. We don't want to mess the exception handling code(like logging, emailing etc) in catch blocks

Could someone post some code samples or literature pointers which we can use to design our simple exception handling framework?

Answer 1

We don't want to expose too much information from BLL to outside world.
(from other layers to bll is fine)

It's BLL itself that defines what's exposed. Make sure You show what's intended to be seen.

We don't want to clutter the code with try catch stacks

Then don't. Exceptions are exceptions. Don't control flow using them. Let them blow up.

We don't want to mess the exception handling code(like logging, emailing etc) in catch blocks

If Your logic does not rely on exception handling (which it should not) and Your code guards itself (this one is important, Your application should ALWAYS blow up on invalid state instead of working further. otherwise - it's hard to understand what causes what), then it's more than enough with wrapping whole app with only 1 error handler that dumps stack trace where necessary.

E.g. - in .net, You can use subscribing to appdomain unhandled exception event for that.

I personally use ELMAH for my web application - few lines in app.config and I have nice error log, stored in sqlite, easily accessable from web app itself. That's about all error handling I got.