It is good practice to handle exceptions as close to the source as possible. This gives you the opportunity to handle the exception in an intelligent way and resume work if appropriate. If you wait to catch it at the page or applicaiton level it may be too late.
It is good practice to handle exceptions as close to the source as possible.
I'd say not. It is good practice to handle errors where it is practical to handle errors regardless of the distance from the source. In my experience, if you handle exceptions too soon you end up writing code that is too defensive and that can actually hide bugs.
Mark Nischalke wrote:
If you wait to catch it at the page or applicaiton level it may be too late.
Absolutely! It is definitely too late to do anything but log the exception at that point.
writing code that is too defensive and that can actually hide bugs
Agreed. As with anything the trick is know when and how to use the tools you have. What I meant was not to just bubble the exception back up the call stack when it can be handled at the source, especially in the case of a class library. If I can recover from an exception in my library I don't want to make it the responsibility of the calling application.
Lets say if you accessing a webservice to retrieve party information and that causes an exception what is the most logical thing to do once it is caught? Im logging them at page and application level. Do I just revert the customer back to that same page where the error occurred and lot it or do I transfer the user back to the homepage and log it. Excuse my ignorance Im a novice with regard to error handling. Thank you
How you handle it depends on the application. Without know how your app is desinged to function I would say to return the user to the page with some message indicating what has happened, i.e "Invalid data", "No record found", etc. Give them a chance to correct any entries. If there is nothing for them to correct, then possibly it would be appropriate to return the to the home page.
With the try/catch exception handling you can provide 'alternate' solutions to any problem that you anticipate in advance... for example, if the db connection fails, or if the page dosn't load, etc. you can do something else for the user so that they don't see some error page or message... my 2-cents
i want to put the calendar in my asp page but in our toolbox have but that is not suitable for web site,is there a tool it's like button or someting when we click that button it should display the calendar(Web Calander).Can anyone help for this pls.
Are sure that the code in the local dev box is the same as that in the live server? You might want to double check the web page with the button that does not work properly.
From my experience, this phenomenon happens with the ASP.NET 1.x, are you using this version? So you may consider using your own code to wire up the event handlers in code-behind instead of using the generated code. Another option is to use the inline code to register the event handler like you have tried, and it's also used by default in the ASP.NET 2.0
I'm not sure if it is actually a bug as I didn't see Microsoft claims about it or I just miss that. But they said, you might have the postback event problem, when you run your ASP.NET on multiple load-balanced servers and the .Net framework 1.1 SP1 has not been installed on all servers. Also when I found that VS 2003 sometimes deletes the auto-generated code containing the event handler registration, I managed to put it on my own.