asp.net 中的异常处理

Question

Just trying my hands with exception handling block with enterprise library 4.0. My application is an asp.net application that has got a DAL, BLL and UI.

When an exception occurs i want to log the relevant scenario/context that would include from DAL(sp, params, exception), BLL (user, role, etc) and UI (session contents). Now i suppose i need to create a custom exception with a dictionary. When an exception occurs in DAL, i populate the dictionary with relevant data at every layer as exception bubbles up. Finally, i log it at App_Error..

Examples over web suggest logging it at DAL itself and then propogate. What do we do to such a propogated exception at BLL, UI layers? Does it mean, it is same as saving the context but every layer itself logs relevant data. And then in log we need to correlate the log statements at every layer to create the context.

Please suggest...

Answer 1

In all the solutions i've implemented of this nature common sense normally dictates that you simply report an error from DAL.

By transactionally executing any db changes you would ensure a rollback is performed and wrap up the actual exception with your own that states that the inner exception occured and as a result no changes were made.

In the BLL the exception is then caught and then further thrown as a custom "BusinessProcessException" for the calling application. Optionally the the BLL because it is in its own "box" so to speak sometimes has its own logging mechanism to log business process related exceptions.

Weather its logged or not at the BLL layer you still need to inform the UI layer (client application) that an exception occurred and was logged passing back the full Exception tree.

The client application code in the UI layer may have its own log but that wont be the log the BLL uses.

The event cycle is something like this...

App calls bll method bll method calls dal method dal method calls stored proc on db stored proc errors throwing (for example) sql exception dal throws new dal exception with sqlexception as inner bll handles dal exception and logs dal fail if there's some transactional element to the bll method that was called, bll rolls back other calls. bll throws new bll framework exception inner is dal exception app handles bll exception and decides what to do to proceed with the user experience from the full exception tree.

This is pretty much how all of .net works.

Things to note:

If i have a business object that fails an update call, that business object may have several child objects that are updated as part of that call. Those child objects could be assembled from multiple dal endpoints on different servers and each dal endpoint may have to update several records in potentially several db's

So you have a transaction for the bll logic and 1 for each dal calls inner workings, and then potentially 1 within each stored proc call.

What .net does in the background is stack these in such a way that if the transaction at the bll level fails and a rollback is called it should rollback all child transactions, however in the real world where transactions span systems and often networks this may not be possible.

You must assume therefore that action you take may fail and can be rollback if any part of the heirarchy fails and the code making the call is responsible for this.

what this ultimately means is that you need a full audit trail of what happened. as a bll dev i log everything that my framework does anyway, sql also has transaction logs so many dal implementations are simplified in this respect.

Applications have (for asp.net) server logs, or custom options only.

The only thing i would recommend is that each layer logs its own activity and logs are separated (eg a ui related error is not really something that belongs in a bll log)