CSLA + Exception/Error Handling

sal2k posted on Tuesday, May 30, 2006

Hello,

I'm just in the process of creating a new application utilizing CSLA 2.0. A question that came up is how are we going to perform Error/Exception handling?

So I thought I would pose this question out to the masses to get an idea on what we can do.

So how about it? Care to share your error handling methodologies?

ajj3085 replied on Tuesday, May 30, 2006

I handle most exceptions in the UI, so that I can give the user an appropriate error message.  However if your business object can recover and still be ina  valid state, you may want to handle certain exceptions within the business code.

Andy

SoftwareArchitect replied on Tuesday, May 30, 2006

I haven't worked out all of the details yet...but I studied the Exception Block from Microsoft and took some of their ideas.

I have a single ExceptionPolicy static class that exposes a HandleException routine.  It accepts the exception and a enumeration on how to handle the error.  For example, from the UI (like from a btn click event) I always call the ExceptionPolicy.HandleException (err, ExceptionPolicyDialog)  which tells the ExceptionPolicy class to use the exception handling logic in another class called ExceptionDialog.  This class knows how to present the exception to the user.   I have other exception handling classes that know how to unwrap exceptions, etc.  They also return a 'rethrow' flag which tells the handler wether or not to raise them out...or if they have been handled and just to resume the normal flow of control.

Hope this gives you some ideas.  The Exception block had WAY more code than we wanted to include with our source and alot more functionality (and learning curve)!

Mike

sal2k replied on Tuesday, May 30, 2006

Those are both excellent ideas. I really appreciate the input - looks like the MS Exception block has some good functionality, but unfortunately, due to time constraints we won't be able to follow that method.

I did however like the idea of having an ExceptionHandling class to take care of presentation to the user!

Thanks again.

PS: I'll post back with what we've decided to do.

RockfordLhotka replied on Tuesday, May 30, 2006

One guideline that I find very useful is to never catch an exception unless you can do something about it. Of course "doing something" can cover some ground - but common actions include:

1. Resolve the problem through app logic
2. Resolve the problem with user input
3. Notify the user (presupposes there is no "resolution" as such)
4. Log the problem
5. Add extra details/information about the problem

The last 2 are quite common, and almost always result in rethrowing the exception (or a more detailed exception with the original inside).

The first one happens from time to time, but since most exceptions are... well... exceptional, it is somewhat difficult to hard-code solutions to them.

Which leaves the two user input options. Obviously those must be handled in the UI, because that's the only layer of the app that is allowed to interact with the user. While any resolution will probably be implemented as part of the object model, the UI layer must be responsible for collecting the user's input.