handling unhandled asp.net exceptions

At some point in their career everyone who creates ASP.NET applications has had issues with their site throwing exceptions that aren’t trapped.  We end up displaying a friendly error page at best, and at worst display the yellow ASP.NET error screen of death.  Generally speaking it’s best practice to configure your ASP.NET application to use friendly error pages so that your users aren’t presented with an exception and stack trace that are meaningless to them.

But how do you find out what exceptions are being thrown by users who are not you?  Over the years I’ve created many versions of the same type of code to handle these situations, so last night I created a project on codeplex that I’m calling sigh.net.  Essentially, sigh.net is a provider based unhandled exception handler for ASP.NET applications.  You can download the source at http://www.codeplex.com/sigh.

It’s extremely simple to use and doesn’t require you to change or add any code to your application.  I currently have an email provider created and am in the process of creating a SQL database provider.

Enjoy!

unhandled addin exceptions vs. visual studio.net

One of the most frustrating things I’ve found when programming addins for visual studio is the inability to globally trap unhandled exceptions the way that you can when  authoring a windows application.  Essentially visual studio intercepts exceptions your addin throws that you neglect to handle.  The worst part is that you don’t get any information about the exception before visual studio crashes!  Its great that Microsoft gets a dump of the crash, but you’re left standing empty handed and scratching your head.