«

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 <>:
> 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.

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?

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 <>
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

[qvo178]

All code should have exception handling in my view.

On Oct 19, 6:23*pm, fe...@palmen-it.de (Felix Palmen) wrote:
> * csharper <gnewsgr...@gmail.com>:
>
> > 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.
>
> 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?
>
> 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 <fe...@palmen-it.de>
> *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

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 <>:
> 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?

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.

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

--
Felix Palmen (Zirias) + [PGP] Felix Palmen <>
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