Free Web-Based Exception Reporting 145
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?"
Hmm (Score:5, Insightful)
Why don't you just add one more function to your SOAP server and have your exception handler connect to that?
[sarcasm]what a great idea![/sarcasm] (Score:5, Insightful)
I wonder what they do with their exceptions.
Only 100 exceptions? (Score:5, Insightful)
Re:It's a solution, but not a complete one (Score:5, Insightful)
There are several reasons for this... you almost never get any sort of reply, most users are practically incapable of writing a useful bug report (what were you doing, what did you click, etc.) and from what I see the majority of the information in an XP error report such as this is just some processor states and a few technical details.
I fail to see how anyone but a machine code professional would decode the XP reports, or how they would know what state the machine was in or why it crashed. The open-source project, OpenTTD, had this same feature for a while until it was scrapped when they realised that no-one could interpret the results or, if they could, it was far too complex, far too time-consuming and far too vague to the programmers.
I'm not saying you COULDN'T make the debug reports much better but then you're basically building every executable in a debug state, i.e. massively bloated and not as good performing, even if you go the highly-manual route and go through the code putting in printf's for each procedure entrance.
Bug reports are invaluable to a programmer but they need to be the right type. Spending 7 hours to trace the machine code route through a hex dump to find that someone was running it on a machine with a corrupt DLL is a massive waste of resources.
Getting experienced beta- and alpha- testers to submit a detailed, reproducible, bug where you can actually ask them to try patches out for you is amillion times more useful
Thanks, but.... (Score:3, Insightful)
Re:Hmm (Score:5, Insightful)
Either that or just register with the site, download a small package and add four lines of code to your program.
So this saves you a few hous work, but costs you confidentiality, full control over the exception database and injects non-free code into your software.
Overall, a pretty louse tradeof.
Great, but have to be careful (Score:4, Insightful)
The key thing to be concerned about (as others have observed) is that any messages sent must be sufficiently generic so as not to give away vital information to the outside world.
When I published my stats, I used abbreviations that only I understood followed by percentages. That's it. If someone else saw it, they wouldn't understand it, and, even if they did, it was just non-vital aggregate information that wouldn't do them any good anyway.
This is the maximum level that such exception reporting could (wisely) rise to, and, as such, would be of limited value. I know from my own experience at large companies that log/exception output tends to contain things like userIDs, passwords, and server names, which could easily find itself passed along through these folks' API.
For this reason, it seems like a good service if installed internally, but a bad idea beyond proof of concept for anything larger than a mom-and-pop, where a single programmer knows and understands the whole system and can send sufficiently vague exceptions.
Re:exceptions? don't use 'em (Score:5, Insightful)
Examples:
1. Your code invokes a method on an object you didn't code, and it throws an exception. Wouldn't it be nice to know where the exception happened?
2. You made an unanticipated mistake! Your code throws a null pointer exception. Of course, if you are perfect, this never happens.
Sensitve Info In Exception Information? (Score:3, Insightful)
Why you would, I don't know. But still.
Pete
Re:exceptions? don't use 'em (Score:2, Insightful)
A more logical response to an exception than graceful handling is actual handling. If you run out of memory, what will you do? If you are receiving null pointers, how can you stop the sender from doing that? If your program is calling an unimplemented function, why isn't your linker catching it?
Exceptions are a way of making easily found bugs difficult to find. They move the instruction pointer far away from the actual error, and unroll the stackframe needlessly.
Log file & safety (Score:3, Insightful)
Re:Hmm (Score:5, Insightful)
Adding this functionality to your code means creating the database, designing an interface to recieve exceptions, an administrative interface to view reported exceptions, setting up a clientside exception handler and a piece of code for marshalling the expception to the server.
Or you could just write a top-level exception handler that e-mails the exception traces to you.
That's one option, but there are lots of other simple approaches that all start with "Catch the exception, put its text into a file and then...". Why complicate this with a database and a custom viewing interface?
Re:Only 100 exceptions? (Score:2, Insightful)
Re:Only 100 exceptions? (Score:2, Insightful)
Because ... (Score:3, Insightful)