Exception handling best practices?

  • Thread starter Thread starter csharper
  • Start date Start date
C

csharper

I am working on an existing asp.net web application.

I see a lot of try catch blocks in the code behind and the exception
message is displayed through a label control in the web form. A lot
of them are simply

lblErrorMessage.Text = ex.Message;

I am concerned about such an exception handling strategy.

First of all, exception messages are not even designed to be seen by
the end users (am I right?), why display it in the web form? Do you
people out there agree? I am still learning, so please correct me if
I am wrong.

Secondly, I find myself quickly out of hands if I have to handle
exceptions on such a fine-granulated resolution (i.e., in each method
where certain kinds of exceptions can potentially be thrown).
Wouldn't it be better to let the exception propagates and handle it in
some centralized location such as global.asax?

Please share your advice on the best practices of exception handling
in an asp.net web application. I'll more questions with regard to
logging.

Thank you very much.
 
* csharper said:
First of all, exception messages are not even designed to be seen by
the end users (am I right?), why display it in the web form? Do you
people out there agree? I am still learning, so please correct me if
I am wrong.
Click to expand...

Well, exceptions are for error conditions, they should never be used for
normal program flow. And, displaying error messages to the user IS
normal program flow. So, you're right. Just a little thing: exceptions
should be seen by the end user in case they are unhandled, so he can
give a meaningful bug report :)
Secondly, I find myself quickly out of hands if I have to handle
exceptions on such a fine-granulated resolution (i.e., in each method
where certain kinds of exceptions can potentially be thrown).
Wouldn't it be better to let the exception propagates and handle it in
some centralized location such as global.asax?
Click to expand...

Uhm, no, not necessarily. You can't handle any exception in a
centralized location, that would require knowledge about any execution
path of the whole application in THAT location.

Handle exceptions that you CAN handle close to where they occur, let
those you can't handle propagate. Optionally create some centralized
exception handler that for example triggers a bug reporting
functionality. Of course, handling an exception does NOT mean displaying
it to the user. If there's some expected user error, try to handle it
without throwing an exception in the first place. Typically for parsing
user input, you want to use the various "TryParse()" methods provided by
the framework. (Custom) validators can help, too.

Regards,
Felix
 
* csharper said:
First of all, exception messages are not even designed to be seen by
the end users (am I right?), why display it in the web form?  Do you
people out there agree?  I am still learning, so please correct me if
I am wrong.
Click to expand...

Well, exceptions are for error conditions, they should never be used for
normal program flow. And, displaying error messages to the user IS
normal program flow. So, you're right. Just a little thing: exceptions
should be seen by the end user in case they are unhandled, so he can
give a meaningful bug report :)
Secondly, I find myself quickly out of hands if I have to handle
exceptions on such a fine-granulated resolution (i.e., in each method
where certain kinds of exceptions can potentially be thrown).
Wouldn't it be better to let the exception propagates and handle it in
some centralized location such as global.asax?
Click to expand...

Uhm, no, not necessarily. You can't handle any exception in a
centralized location, that would require knowledge about any execution
path of the whole application in THAT location.

Handle exceptions that you CAN handle close to where they occur, let
those you can't handle propagate. Optionally create some centralized
exception handler that for example triggers a bug reporting
functionality. Of course, handling an exception does NOT mean displaying
it to the user. If there's some expected user error, try to handle it
without throwing an exception in the first place. Typically for parsing
user input, you want to use the various "TryParse()" methods provided by
the framework. (Custom) validators can help, too.

Regards,
Felix

--
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <[email protected]>
 web:  http://palmen-it.de/ |            http://palmen-it.de/pub.txt
 my open source projects:     |   Fingerprint: ED9B 62D0 BE39 32F9 2488
 http://palmen-it.de/?pg=pro +                5D0C 8177 9D80 5ECF F683
Click to expand...

Thanks for sharing your ideas.

Yes, "Handle exceptions that you CAN handle close to where they
occur", I get that idea, but isn't there also an issue of whether I
SHOULD handle the exception?

In other words, how do I determine if I SHOULD handle some exception
close to where they occur and I do have the capability of handling it?

Oh, btw, I don't mean to digress (or hijack my own topic), but this
newsgroup used to be pretty active with genuine programmer
discussions, but now it is full of spams and not many people are using
it any more. So, the once unbeatable Google has been defeated by
spammers.
 
* csharper said:
Yes, "Handle exceptions that you CAN handle close to where they
occur", I get that idea, but isn't there also an issue of whether I
SHOULD handle the exception?

In other words, how do I determine if I SHOULD handle some exception
close to where they occur and I do have the capability of handling it?
Click to expand...

Hmm I'd define the capability to handle an exception as knowing a sane
way to recover from the error condition, so the intended functionality
can still be achieved. For example, in an application I wrote for
tunneling some TCP connections through http, I am occasionally
confronted with WebExceptions and SocketExceptions when some
communication timed out. Although this is an error condition, there is a
sane way to recover: Just retry sending the same data.

If there is no chance to accomplish the intended task, I'd let the
exception propagate up the caller stack -- you could put your central
handler there, but it probably can't do any more than informing the user
and/or the developer about what went wrong.
Oh, btw, I don't mean to digress (or hijack my own topic), but this
newsgroup used to be pretty active with genuine programmer
discussions, but now it is full of spams and not many people are using
it any more. So, the once unbeatable Google has been defeated by
spammers.
Click to expand...

I don't really get what links google to this newsgroup? I'm certainly
not using google to access it. The extremely low traffic probably has to
do with microsoft's decision to drop usenet (a particularly bad one if
you ask me). It's already been discussed several times in the
microsoft.* hierarchy, though.

Regards,
Felix
 
Back
Top