Tech Off Thread

2 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

ASP.Net Exception Hanlding Practices

Back to Forum: Tech Off
  • User profile image
    dehranph

    What are your ASP.Net Exception Hanlding Practices based on these different scenarios. Kindly share some of yours.

    1. Exceptions thrown due to database update constaints, such as PK constraints, Unique contstraints,  custom constraints, etc... Do you use return codes from your SP or simply print "Record Already exsits!". How did you convert those CRUD SP errors to a friendly message that ordinary users will understand at its very basic terms and right away they will understand the best thing to fix it and what not to do next time.

    2. Do you maintain in the database all those messages such as Error Codes, What Happen, How this affect you, What To Do To Fix or just  in XML file to benefit from localization.

    3. Oh by the way, do you  use Error Codes?

    4. How you take care of unhandled exceptions? Page level or Application level? What make application  level  better over the other. If there other i havt mentioned, please do post them.

    5. What enterprise application blocks or helper classes are you using for handling and logging those exceptions. I havent tried log4net or EntLib if this is applicable for a web app.

    Any inputs? Thanks in advance!

  • User profile image
    kidzi

    Well, for #1, I'd think errors like that are things you shouldn't allow. Using a PK Constraint to tell you that the 'record alredy exists' is lazy programming. When done correctly, Crud SPs should never return errors unless there really is an exceptional issue.

    Before inserting, do a check to see if it's already there. Why can the user even 'insert' something if its already there? Doesn't the UI block that operation? If you had somethign checking for existence first, you could have a popup saying that record is already there before trying a crud operation.

    Exceptions should not be used for flow (when this exception happens, display a messagebox telling the user record already exists).

    When an exception happens, just tell the user something is messed up, then email or log the error so that whoever is monitoring the app can see it and react appropriately to resolve it for good.

    Making your own exception handler is useful, and having an XML file that can be configurable to certain types of errors maybe keying on: method name, application name, version, etc. is useful so that if there is a problem that you cannot fix right away, you can map the message override to the particular error saying either that you're working on it, or providing a workaround in the mean time. When the issue is fixed, just remove it from the xml file and continue on. An xml file on the file system is easier because it removes a database dependency. You want your error handler to not require many external dependencies. Of course, logging to a database and such is fine as long you have backup logging in case it fails. I used to use the event log, a database, and an email. The email so that I know immediately there is an issue, the database for metrics, and the event log in case I'm working with a user's machine and generate the error and need to see more info.

    Good luck.
    Kevin

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.