CODEWITHSUNDEEP
c#.netarchitectureexception
Panks
Panks

Reputation: 611

Exception handling in layered architecture

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?

Upvotes: 4

Views: 4185

Answers (3)

Sandeep
Sandeep

Reputation: 7334

Eric Lippert has a wonderful article on how to handle exceptions. I think it would be useful.

Upvotes: 2

Ladislav Mrnka
Ladislav Mrnka

Reputation: 364409

Exception handing can be as complex as you want but the good way is to use some global definition. For example by aspects which you can build with any AOP framework - part of most IoC containers like Unity, Windsor Castle, Spring.NET. Separate category of AOP frameworks is PostSharp which adds aspects on compile time insted of runtime.

Also you can check Enterprise Library 5.0 and its Exception handling application block which allows you to do policy based exception handling out of the box.

Upvotes: 1

Arnis Lapsa
Arnis Lapsa

Reputation: 47647

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.

Upvotes: 3

Related Questions