I looked around and wasn’t able to find an exception reporting system like elmah for the PHP world. So I wrote one. Now more are starting to come out of the woodwork.
sounds like you’re trying to justify something!
The silent exception reporting is all well and good until you find yourself working with people who really don’t want any of their data being passed out of their own network, or whose network isn’t connected to the internet consistently. At that point you end up spending a lot of time on the phone.
Also, @Jim: Lighten up.
sure, it isn’t the greatest approach 100% of the time, but it does have merit.
Oh, and jim, lighten up 
so, what would you do when your’re developing very content intesive (image, video, swfAS2/swfAS3, xml content files, etc) a RIA in flex?
most errors we get are not simply caught by try/catch. there is no catchable exeption for a misidentified swf format (as2 instead of as3, which simply displays the first frame), a browser crash because the adobe plugin doesn’t like h264 or for data not being displayed because of a wrong set of config files. These are examples for the program working perfectly within given parameters nevertheless producing situations which are recived by the user as errors.
So, I think, when you come down on us for not knowing an error before the user does, you speak mostly for excel-like .NET applications for database organization. there are some problems in real life which aren’t behaving according to microsoft standards…
excellent, thanks for the info.
I had a refreshing discovery when starting a project in django recently, where when in debug mode the framework dumps a well-formatted stack trace that even includes sections you can expand to reveal local vars for each frame. Once you deploy your application and turn off debug mode it stops dumping the stack trace and instead emails any number of site admins with the error details. However I do like the idea of a central exception log like you showed above, which would probably be easy to do with some django middleware.
I would say … for server based code this is just fine. For client based code this is tricky, because if you iterate often you have to keep track of versions and all that nightmare. For client code I’d advocate TDD.
how ‘agile’ of you jeff.
When I hear people say things like, Real software is hard and is hard to learn. I feel really disheartened.
A good developer makes difficult tools easy to use… as long as management, and often the users themselves, will get out of your way and allow you to do your job.
I completely agree. In fact we adopted ELMAH for our SharePoint environment and it was the very first task in our first Sprint for our big SharePoint Redesign.
We also have a complete environment where users can use the code for immediate feedback and user testingbefore it gets to production.
Nice article, thanks!
I agree, correct exception handling is the principal of software quality. Exception handling practices are well-documented, but there are so many developers who can’t apply them: you can find crazy try/catch blocks at a lot of parts of the code. This is the reason why I prefer centralize/encapsulate the error handling. I wrote a short article on how to implement it with AOP features of Spring.NET (PostSharp is coming soon).
http://www.coderecycling.net/2009/04/centralized-exception-handling-logging.html
I use XML data type (feature of MS SQL 2005 and 2008) for error logging, this enables me to add extra information without the need of database structure modifications. I can make more detailed queries by XQuery and build error reports with XSLT.
All Jon Skeet’s code is exceptional!
Microsoft has been doing this for years, thus leading to their current remarkably high level of quality?
Exception reporting is great, but if you put out crappy software as a baseline, you’re still putting out crappy software. If you’re fixing that much stuff due to your exception logs, you’re doing it wrong.
I’ve had the same issue with production sites. But I never seem to eliminate 100% of the issues. There are still many issues with corrupt VIEWSTATE etc … that are sometimes unpredictable to impossible to solve.
I wish .net had a better logging/exception handling system that could Snapshot the state of the process for you. Variables/Requests. It would go a long way in trying to fix these pesky production exceptions.
I don’t think I’ve ever had an event viewer log free of errors in my entire career. It’s a lot of effort to stay on top of every issue. 
Event viewer / logging does a terrible job of not allowing you to ignore errors. If someone sends a bad request to my DNS server for example … do I really need it as an error in the event viewer? They’re the ones who sent the bad request. lol
For winforms…would you still recommend the code you published on codeproject at http://www.codeproject.com/KB/exception/ExceptionHandling.aspx. It is 5 years old now. If you were to do a winforms app what would you use?
Seth
We adopted AVICODE, its pretty good.
For Winforms, you’ll probably want to take a look at Exceptioneer.
It’s starting to shape up with some great features and just added support for winforms:
I hope you will think again twice before saying: “Ship your software, get as many users in front of it as possible, and intently study the error logs they generate.”
You are practically saying that the final user (the client of your application) is the tester of the application.
How many years in PM do you have? Keep practice this philosophy and you will loose all your customers … and fast!