4

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?

Improve this question

3 Answers 3

Reset to default
3

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

I disagree with the notion of letting inner exceptions bubble up. If a method called from your code throws an exception which represents a condition it's possible your caller might want to handle, you must wrap the exception in one of your own, defining the condition. If abstract class DatabaseWrapper has implementations SqlServerWrapper and MySqlWrapper, and one is writing a AcmeDatabaseWrapepr for the AcmeDatabase class, a decision by an AcmeDatabasseWrapper to let any derivative of AcmeDatabaseException percolate up is a decision not to let the caller handle the exception usefully.
Since it should be the caller, rather than the wrapper, which decides whether a particular situation should be handled, the AcmeDatabaseWrapper class should endeavor to catch all exceptions thrown by AcmeDatabase and wrap them in derivatives of DatabaseWrapperException, such as DatabaseWrapperTableNotFoundException, DatabaseWrapperInvalidQueryException, DatabaseWrapperSystemOnFireException, etc.
@supercat exceptions are specific form of communication. they make sense ONLY when you got no control over client that uses your code. in regular business line application, no matter how much layers there are, usually you have this control. I'm not talking about building framework or something like that.
I wasn't thinking in terms of a framework, but something like a database communications layer. It should be possible to add support for additional database classes by writing new wrapper classes, without having to change the application code to intercept new kinds of exceptions (or change it in any other way, for that matter, except to make it add a new database-connection factory to the list).
I think it is worth to mention performance issues arisen from bubbling the exceptions up.
2

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

Improve this answer

Comments

1

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.