Free Web-Based Exception Reporting
Tsar writes "Promethean Personal Software (makers of Sherpa, a code generating tool for db apps) have quietly released ExceptionCollection, a free (as in beer) online service for developers using any SOAP-enabled environment. You sign up on the site, download their component, add three or four lines of code to your app, and any exceptions thrown by your users get logged at ExceptionCollection.com for your later perusal (the last 100 anyway). There are several options, like whether reporting requires user approval. Is this as cool as it looks, or a solution in search of a problem?"
This application is better in that it collects all the relevant information into a zip file (including a stack dump), and helps the user to e-mail it to you. It works in C/C++ (Windows only) and doesn't require any third party involvement.
We use it in a deployed product and it works very well.
john
No, ma'am. Had you read my post you'd see that I had said 5 or 6 million hits. Now consider that even just 1% of those 5 million hits throw an exception. That's 50 000 exceptions.
More realistically, even if just 0.1% of those 5 million hits throw an exception, you're looking at 5000 exceptions. That's 50 times the number of exceptions this site will list. A whole lot of data is being lost.
Cyric Zndovzny at your service.
This sounds similar to the BugzScout support in FogBugz (www.fogcreek.com), except that there the errors get sent to your own database on your own web site, and are not limited to the last 100. Definitely cool and valuable to track where your application is breaking, and have the ability to report back to customers whether a specific problem is fixed, being worked on, or needs help to track down.
Huh ? I don't know how you do that in your part of the world, over here we just have a mail component in the server-side software that generates an error email in the exception handler and mails it to an address configured in the server process by some means you like (config file, hardcoded (*ugh*), you name it). Not much more bother than using some remote service.
The minidumps generated by XP are actually extremely powerful, assuming you've got good project management. You can load up the minidump in a debugger and it will restore the application state at the time of the crash. It can load the debugging info and symbol maps from local files, so you can still ship release binaries.
I once had an issue with my compaq blue screening returning out of sleep mode, I'd installed every update on compaq's website and scoured the net for a solution.
One day out of sheer desparation I decided to send the report off to Microsoft and to my surprise it came back with a link to a support website giving very obscure step by step instructions which magically resolved my problem.
I don't often get exceptions in windows where I'm at a loss for an explanation as to the cause, but in future when I do I'll definitely be posting them to Microsoft.
Not if its a web application. We use this system at my work place, with the addition of generating an RSS feed from the emails. Basically, when we put the app on production, we just have to change the smtp server property in our web.config to point to the correct smtp server.
If you're running an actual local application, then you'll run into problems. But if you have clients that work in one area (say, a custom in-house application), then the exception reporting works beautifully. Its really quite a good system for the majority of applications.
If someone is using .Net then there is something FAR better already (it's not new either): the EMAB [Exception Management Application Block], which is part of the Microsoft Enterprise Library. You get the full source code, and it has been tested extensively. They're very well documented (lots of articles on the web too) and come with samples and everything you need to get started. It's easier to setup and use (imho). Publishing exceptions take only 1 line of code (in your catch blocks), and it's far more flexible than this - it can publish your exceptions in different ways (to a database, email, etc). You can change the configuration to publish it in other ways anytime you please. It's a good, consistent and easy way of handling exceptions.
As a bonus, you get 6 extra application blocks if you want to use them: caching, configuration, cryptography, data access, logging and instrumentation, security. They're quite useful and can speedup development.
You get to log as many errors as you please, no privacy issues or any of that stuff.
///<sig