.NET news » ASP.NET 
How to enable Skype features in your ASP.NET website
3-tier Architecture with ASP.NET 2.0: Tutorial 6: Programmatically Setting the ObjectDataSource's Parameter Values (Visual Basic)
3-tier Architecture with ASP.NET 2.0: Tutorial 6: Programmatically Setting the ObjectDataSource's Parameter Values (Visual C#)
3-tier Architecture with ASP.NET 2.0: Tutorial 5: Declarative Parameters (Visual Basic)
3-tier Architecture with ASP.NET 2.0: Tutorial 5: Declarative Parameters (Visual C#)
DateTime Values according to the remote time zone
A Visual Basic Developer's Introduction to ASP.NET 2.0
A Visual Basic Developer's Introduction to ASP.NET 2.0
HTMLEditor Provider - How to write a custom provider for ASP.NET 2.0
Gracefully Responding to Unhandled Exceptions - Displaying User-Friendly Error Pages
In .NET applications, an illegal operation - an invalid cast, attempting to reference a null value, trying to connect to a database
that's been taken offline, and so on - raises an exception. Exceptions can be caught and handled directly in code
through the use of Try / Catch blocks. For ASP.NET applications, if the exception is
not handled in code, it bubbles up to the ASP.NET runtime, which raises an HttpUnhandledException.
By default, unhandled exceptions result in a page that displays the text, "Runtime Error" with instructions for developers on how to display exception details
(see the screen shot to the right). This "Runtime Error" error page is what is seen by external visitors; if you visit your site through
localhost and an unhandled exception occurs, the default error page includes the type and details of the exception thrown.
End users will no doubt find the "Runtime Error" page to be intimidating and confusing - do you think the average computer user knows what "Runtime" means? All the user knows is that something went horribly wrong. They might fear that their data or progress has been lost and that they are responsible for the error. Ironically, the person who does care that an unhandled exception has occurred - the developer - is left out of the loop unless the end user takes the time to email the developer the details of the error (what page it happened on, the steps the user had performed that caused the error, and so on)..

