Exception Management contradiction

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

I am currently in the process of switching our application to a N-Tier model
with .NET.

One of the aspects we want ot get right from the start not to worry about it
after is the Exception management.

I have read two MSDN documents that appear to be in contradiction, and I
would like to know if someone can explain to me which of the two is the
recommended approach.

The documents are "Exception Management in .NET" and "Application
Architecure for .NET: Designing Applications and Serivces."

In general, the contradiction I found lies in how to handle the logging and
notification tasks when managing unhandled exceptions.

The first document "Exception Management in .NET" recommends to perform
logging and notifications right before displaying the exception information
to the user:
"When an unhandled exception propagates to the last point or boundary at
which your application can the handle exception before returning to the user,
your application can no longer recover from the exception. At this point, it
mus gather information, log information, send any notifications, ...."
"In most Web-based applications, this boundary is controlled by your ASP.NET
code..." (from page 13)
Then it goes to explain different mechanism availabel in ASP.NET to handle
exceptions.
It also states: "An exception management system should be well encapsulated
and should abstract the details of logging and reporting from the
application's business logic." (from page 1)

This is all fine and makes sense, exceptions are handle and propagated in
all layers of the application, and the UI takes care of logging, notifying
and ultimately displaying the relevant information.

But the, I found something in "Application Architecture for .NET: Designing
Applications and Services" that makes me wonder if I am getting it wrong.
It mentions hwo exception management should be achieved at each layer.
UI Components:
"User Interface componnents should publish their exceptions ... It is common
to publish to some central server and/or local file or event log."
(so far this is just dandy, it goes along with the first document)

Business Components:
"Exceptions should be publish in business layers, because this is where
transaction outcome is known and internal serice level agreement are defined."
(Are we talking about logging and notifying? this does not sound in
accordance with the first document. What about the "boundary before returning
to the user" ?)

Data Access Components:
"Data Access Components should always publish their exceptions by writing
exception details to a log file ..."
(Now I am confused)

I really dont mind which one of the two is correct, personally, the first
document makes more sense to me (but this post is long enough as it is to go
into that.)

What I really would like to know is which of the two approaches is the
recommended and if there is an explanation for this contradiction ?

Thanks in advance
 
I don't see a contradiction.

The first article is discussing unhandled exceptions. These are exceptions
that you did not expect.
The second article is discussing where to put exception handling for
exceptions that you would expect would occur. These would be "handled"
exceptions.

My rule of thumb: keep exception handling as close to the code that created
the exception as you can. Have business objects respond in a sensible
manner when exceptions occur. Build the exception behavior into the
behavior of the object. (e.g. if you tell a business object to "go get
data", it should use a data accessor object that understands how to respond
when the database connection is lost. On the other hand, credentials issues
would have to "bubble up" since the business object layer cannot handle that
exception any better than the data access layer could... it's up the user to
provide credentials).

Good Luck,
--- Nick
 
Back
Top