Exception handling best practices?

Discussion in 'ASP .Net' started by csharper, Oct 19, 2010.

  1. csharper

    csharper Guest

    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, Oct 19, 2010
    #1
    1. Advertising

  2. csharper

    Felix Palmen Guest

    * 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
     
    Felix Palmen, Oct 19, 2010
    #2
    1. Advertising

  3. csharper

    qvo178

    Joined:
    Aug 28, 2008
    Messages:
    19
    All code should have exception handling in my view.
     
    qvo178, Oct 20, 2010
    #3
  4. csharper

    csharper Guest

    On Oct 19, 6:23 pm, (Felix Palmen) wrote:
    > * 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


    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, Oct 20, 2010
    #4
  5. csharper

    Felix Palmen Guest

    * 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
     
    Felix Palmen, Oct 20, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?U2FuZHk=?=

    Error Handling - Best Practices

    =?Utf-8?B?U2FuZHk=?=, May 6, 2005, in forum: ASP .Net
    Replies:
    4
    Views:
    609
    =?Utf-8?B?U2FuZHk=?=
    May 7, 2005
  2. Bill Fuller
    Replies:
    5
    Views:
    398
    sloan
    Aug 13, 2007
  3. MaksimKneller

    error handling best practices

    MaksimKneller, Aug 23, 2010, in forum: C++
    Replies:
    22
    Views:
    1,259
  4. Ryan N.
    Replies:
    2
    Views:
    188
    Ryan N.
    Feb 11, 2004
  5. snarf
    Replies:
    7
    Views:
    115
Loading...

Share This Page