Exception Handling in WEB

Topics: Exception Handling Application Block
Oct 16, 2009 at 3:53 PM

Could somebody provide me guidance (or a short real example) of how to handle DB errors in a WEB page using Entlib? My app consists of WEB UI layer, a Business Login Layer (BLL) and a database logic layer (DLL). I have been confused as of where (in which layer) exactly to write the exception handling code in order to log the DB error, and also to change to a friendler message, to be displayed in the page. I've read something about writing exception management code at layer boundaries, but I just got more confused.

Is it true that I should leave the database layer exceptions unhandled. and just catch them in the  BLL where the DLL is called and then immediatelly replace the exception with another one with a friendlier message to be bubbled up to the WEB UI, where the first try/catch was started? (Just thoughts of a newcomer to EHAB...)

Any help is appreciated

TIA

Iordanis

Oct 19, 2009 at 5:38 AM

Hi,

May i ask for the link where have you read the statement above? It depends on your requirement, you can catch the exception on the DLL then log it, pass it to the BLL then do a replace(cleaning the exception), then pass it back to the UI to show the message to the user. You can also have the BLL do all the logging ang the cleaning of exception before sending back to the UI.

Valiant Dudan
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

 

Oct 19, 2009 at 1:50 PM

Well it's been a while since i've read that, so I don't remember the exact site. But anyway isn't it better if I avoid catching exceptions in DLL, since I'll only get the database message. That way, less coding is required, and also fewer places to check. So as I understand, it's ok to to the main exception handling in the BLL, where all the logging and other stuff can also be done, and right there, replace the exception with one with a friendlier message for the user (that is in the UI's exception handling, just display the message and don't do anything else). Am I correct?

Also, is there any real WEB example for the EHAB? I mean, that is should contain the DB, the DLL, the BLL and the UI, that someone can use as a guidance? The more complicated it is, the better.
I think many people (like me), are just surfing around the Entlib help file, without being sure what to write and where to write it.

TIA

Iordanis

Oct 20, 2009 at 3:36 AM
Edited Oct 20, 2009 at 4:20 AM

Well, I think you just agreed with what you have read.

"Is it true that I should leave the database layer exceptions unhandled. and just catch them in the  BLL where the DLL is called and then immediatelly replace the exception with another one with a friendlier message to be bubbled up to the WEB UI, where the first try/catch was started"

I don't see anything wrong with this, you could have an exception policy which first has a logging handler which will log the original exception and then a replace handler which does the replacing with user-friendly messages.  As for the web example, there's none included in the quickstart, and requirements differ for every application. But I think, since EHAB is simple to use, I'd suggest you just look for best practices on handling exceptions in web applications and based on that, make use of EHAB to apply those best practices.

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Nov 4, 2009 at 10:50 AM
Edited Nov 4, 2009 at 1:03 PM

Back after a few days! Thanks for the response. One other thing that I try to figure out is, what I should do if in the same try/catch block, I want to mix friendly DB error messages, with Application friendly error messages. To explain, further, imagine the following try/catch block :

try
    SomeDBCallThatCanGoWrong(...)
    SomeAppOrValidationCallThatCanGoWrong(...)
    SomeOtherDBCallThatCanGoWrong(...)
catch ex as exception
    if ExceptionPolicy.HandleException(ex, "DB Policy") then throw
end try

The 1st and 3rd statements are probably calling some DB stored procs, through DB App Block. So it should be handled using a default DB friendly message, depending on the DB error type (SqlExceptionWrapHandler is excellent, although with a major disadvantage of not being localizable).

What if the 2nd call needs to create an exception with a varying validation message? It would be caught by the "DB Policy" and the user would not understand it, because it is not DB dependent but it's an application validation. Which solution is the best here?

TIA
Iordanis

 

Nov 6, 2009 at 3:20 AM

Why not catch for specific exceptions? Have a catch for an SqlException and a separate one for another type of exception which you want to treat differently by applying a different exception policy.

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

 

Nov 6, 2009 at 7:49 PM
Edited Nov 6, 2009 at 9:50 PM

OK, but for the above example, doesn't it mean three separate try/catch statements (one for each call)?  Instead, could I just set 3 exception types inside the "DB Policy" in web.config? In the latter case, how can I specify the order of importance (specific to generic) for the exception types? Using the config tool, I don't see any option. It just lists the exception types alphabetically (and I'm too afraid to touch the web.config by hand)

Nov 9, 2009 at 1:47 AM

Should have thought about that, yes you could just set 3 exception types inside the Db Policy exception policy.  Regarding on your concern about the setting the order of importance, it's not how it's listed in the config.  EHAB gets first the exception policy to use and then specifically gets the type of the exception to handle and applies the custom handler that you define for that specific exception.  If the exception is not included in the exception policy, it uses the generic Exception type (if it's included in the policy).

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com 

Nov 9, 2009 at 5:45 PM

So, you say that the order of exceptions, as it appears inside web.config, doesn't matter at all? That is, either the excact exception is handled or the default one? Then why in .NET help says, "be careful about the catch order"?

Nov 10, 2009 at 1:17 AM

Yes, because you are using EHAB which takes care of handling your exact exceptions.  You're worrying about the .NET case because yes, if you're going to catch your exceptions using pure .NET, the order does matter.  If your first catch is for the generic Exception type, then all the succeeding catch won't be executed.  But in EHAB, it gets the exact type of the exception and applies the appropriate handler.  You can do a simple test on this.  Create an Exception Policy, add first an Exception type and apply any handler you want.  Then add a specific exception like ArgumentException and configure again an exception handler.  In your code, throw an ArgumentException and handle it using the exception policy you've just created.

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com