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?"

Comments

exceptions? don't use 'em

[Anonymous Coward]

I don't like exceptions because you have to catch them. Exception based coding is for amateurs.

Real professionals like me, who graduated at the top of his class from Rockhurst College in Kansas City, a top college - pass return codes around rather than do all that exception baloney.

And it is some big time BALONEY.

Re:exceptions? don't use 'em

[mysticwhiskey]

And the exception's travelling far out-field, up, up , up! Yes, there's the AC, he's under it, almost a certain catch! NO! He doesn't catch it! What's this? He writing on post-it note! He hands it to the umpire... let's switch to the umpire-cam... and the result is... "Code -99 : Exception not caught, glove object not instantiated".

Re:exceptions? don't use 'em

[Jeremy Singer]

What if your code throws some exception you weren't expecting, even though you use return codes?
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.

Re:exceptions? don't use 'em

[Anonymous Coward]

Wouldn't you be able to catch either of those in debug?

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.

Re:exceptions? don't use 'em

[Fred_A]

Well, as long as people from Kansas use more SOAP, I'm all for it.

(ducks and runs)

Hmm

[elronxenu]

Let me see if I have this straight. You run a SOAP server, and you use this vendor's library so that your users (who are presumably remote to you, but running your code) will report their exceptions to the vendor's database, which you can query later.

Why don't you just add one more function to your SOAP server and have your exception handler connect to that?

Re:Hmm

[/ASCII]

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.

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.

Re:Hmm

[swillden]

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:Hmm

[should_be_linear]

Or you could just write a top-level exception handler that e-mails the exception traces to you.
This is quite bad idea because you must have UI for setting up smtp, port (proxy?) username, password.... In the end, all most users would see when exception occures is "Unable to connect to SMTP sever x".

Re:Hmm

[Rycross]

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.

Re:Hmm

[Nik13]

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.

It's a solution, but not a complete one

[ReformedExCon]

There is a definite market for something like this. Knowing what exceptions your application is generating at runtime "in the wild" is very valuable to help debug and speed bug fixes.

The only problem is that it would be much more convenient if the exception were sent directly to the application makers instead of to some third party. Microsoft's error reporting system is somewhat like this, but I don't know anyone who actually sends in bug reports when an application crashes in XP. Likewise, Firefox used to have a quality feedback agent, but I never saw it pop up or notify me in any way. Maybe it is silently calling home?

If your users are your testers, it's very important that you get as much detailed information from any problems that arise as you can. Ideally these bugs would have been fixed before it ever hit the doors, but in this day and age of rapid development and short production cycles, it's sometimes better to give a working version to the customer and update it periodically.

Re:It's a solution, but not a complete one

[ledow]

"but I don't know anyone who actually sends in bug reports when an application crashes in XP"

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

Re:It's a solution, but not a complete one

[arkanes]

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.

Re:It's a solution, but not a complete one

[Darkling-MHCN]

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.

[sarcasm]what a great idea![/sarcasm]

[aranganath]

I can't think of any reason NOT to send detailed information about where my application is broken and possibly exploitable to one centralized location that I maintain no control over.

I wonder what they do with their exceptions.

Re:[sarcasm]what a great idea![/sarcasm]

[Anonymous Coward]

Are you being sarcastic?

Re:[sarcasm]what a great idea![/sarcasm]

[flatface]

[Informative]Yes he is.[/Informative]

Only 100 exceptions?

[CyricZ]

It only allows the developer to see the last 100 exceptions? That might be fine and dandy for a site that only receives 100 hits per day. But when you're running an enterprise-grade site that gets 5 or 6 million hits on a slow day, 100 exceptions will basically be nothing. You could probably sit there and refresh the list of exceptions, getting a completely new list each time.

Re:Only 100 exceptions?

[CyricZ]

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.

Re:Only 100 exceptions?

[Pulse_Instance]

If your getting anywhere that many exceptions a day it is high time that you invest some money in testing. Whether this testing be having the developers take some training in what testing actually is or having actual testers do the job, either option will save you time and money in the future.

Re:Only 100 exceptions?

[danhirsch]

"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." If you are even throwing 5k execptions in a day on an ENTERPRISE site...you have more problems to deal with...like learning how to CODE a stable site. If you had a common enough exception for 5000...your going to get allot more than that. Even with 5000 exceptions bad bad things are happening. Fire and brimstone coming down from the skies. Rivers and seas boiling. Forty years of darkness. Earthquakes, volcanoes... The dead rising from the grave. Human sacrifice, dogs and cats living together - mass hysteria!

Re:Only 100 exceptions?

[tgd]

Do not put a link to this post on your resume.

Trust me.

Re:Only 100 exceptions?

[danhirsch]

Further if an enterprise site is using a freebee exception tracking service...well..I really don't have to say anything do I.

Great for spyware

[G4from128k]

1. Collect data from unsuspecting users of your SOAP code.
2. Throw an "exception" containing said data.
3. Automatically harvest the data from ExceptionCollection.com.
4. Profit.

I wonder if these people have thought about the insecure/immoral/illegal ways this service could be used and have taken steps to prevent that.

A better solution

[jdh28]

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

Thanks, but....

[barzok]

I think I'll stick with recording my exception logs in my own database where I have some measure of security around it, and can look at all of them, not the last 100.

similar to BugzScout in FogBugz

[smartgo]

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.

whatever happened to....

[amodm]

old style logging. why not just log the exception to a file (as its usually done), and mail it to the programmers at a regular interval. why waste so much of bandwidth, especially in the case where things go horribly wrong and exceptions are thrown just about everywhere.

also, is this mechanism asynchronous ? coz synchronous would mean a lot of latency added to that particular thread, since things are now getting reported to some remote portal.

IMHO, its just another wasteful use of web services. just coz its the fashionable term these days doesn't mean it should be used for all purposes.

web services for exception reporting.....aarrgghhhh !!!

Re:whatever happened to....

[Wudbaer]

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.

Great, but have to be careful

[CrazedWalrus]

I used to do something like this using my personal web site. I didn't use it for exception reporting -- just for publishing generic statistics about our production stream. I could then monitor them remotely from my cell phone's web browser.

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.

Sensitve Info In Exception Information?

[Pants75]

Remember to strip out an connection strings/password etc from you exception info if you're think of using this...

Why you would, I don't know. But still.

Pete

solution vs problem?

[AnObfuscator]

is this as cool as it looks, or a solution in search of a problem?

Or? What kind of nerd ARE you?! Duh, it's BOTH!

In fact, a good case could be made that it looks so damn cool BECAUSE it is a solution in search of a problem!

Log file & safety

[jurt1235]

Just keeping the exceptions in the logfiles so you can literary put anything in the exception what you want, not having to wonder if some debug information which happens to be equal to a clients transaction wanders around on the network or even the internet. Plus logfiles can be analyzed too, enough handy tools around for that too (I use vi).

Re:Log file & safety

[azaris]

Plus logfiles can be analyzed too, enough handy tools around for that too (I use vi).

You have a magical version of 'vi' that penetrates the user's firewall, reads their logfiles over the Internet and reports back?

GET DOWNSTAIRS AND WASH MUMS CAR !

[Anonymous Coward]

if you are going to take the day off school you can start by helping your mum

An exception has occured

[DeadSea]

Exception: Could not handle error: an additonal exception was encountered
at com.example.util.BaseExceptionHandler() Line 450
...
Root Cause:
OutOfMemoryError: Out of memory during exception construction
at Exception() Line 5
...
Root Cause:
IOException: Could not connect to exceptionollection.com
at com.ExceptionCollection.reportException() Line 127
...
Root Cause:
ApplicationException: HelloWorld program is too simple
at com.example.webapp.HelloWorld.print() Line 907
...

Because ...

[PetoskeyGuy]

You'll end up paying them for use of the patent anyway.

Copyright 2005, Promethean Personal Software
Patents pending.

Exceptions?

[irablum]

I don't know about you guys, but I don't have any bugs in my code. It works perfectly the first time. No doubt. Never happens. Nothing ever breaks. Ever.
hah.
so there.

at java.util.zip.InflaterInputStream.fill(InflaterInp utStream.java:215)
                at java.util.zip.InflaterInputStream.read(InflaterInp utStream.java:134)
                at java.util.zip.ZipInputStream.read(ZipInputStream.j ava:139)
                at java.io.FilterInputStream.read(FilterInputStream.j ava:90)
                at jrunx.util.JarUtils.expandJar(JarUtils.java:110)
                at jrunx.util.JarUtils.expandJar(JarUtils.java:142)
                at jrunx.util.URLUtil.makeExpandedCopy(URLUtil.java:1 07)
                at jrunx.util.URLUtil.makeExpandedLocalCopy(URLUtil.j ava:70)
                at jrun.deployment.DeployerService.createWatchedDeplo yment(DeployerService.java:213)
                at jrun.deployment.DeployerService.deploy(DeployerSer vice.java:430)
                at jrun.deployment.DeployerService.redeploy(DeployerS ervice.java:1407)
                at jrun.deployment.DeployerService.redeployChanged(De ployerService.java:872)
                at jrun.deployment.DeployerService.run(DeployerServic e.java:890)
                at jrunx.scheduler.SchedulerService.invokeRunnable(Sc hedulerService.java:223)
                at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRu nnable(ThreadPool.java:426)
                at jrunx.scheduler.WorkerThread.run(WorkerThread.java :66)

damnit