Thrown exceptions used for bug tracker

Submitted by tyhullinger on Wed, 05/20/2009 - 18:34.

I have just recently glanced across some of the code and noticed that most if not all exceptions in the Jnode code have been thrown. My thoughts were that you could code a custom bug tracker that will tell what application was run and then when an exception is caught send it to a mysql database possibly on this server? As I can see so far the implementation of this will be fairly easy. It could even be possible to create a randomized hash for each persons machine that could be updated as bugs come across for further fully featured bug tracking.

All feedback is welcome.

‹ awt gui doesn't work on sun virtualbox Removing **my** unused/incomplete/unneeded features ? ›

Privacy

Submitted by Stephen Crawley on Wed, 05/20/2009 - 23:10.

I cannot make sense of your first sentence ... but logging bugs is certainly an interesting idea.

But there are major privacy concerns.

  • Even with randomized hashing (whatever you mean by that), it is possible to correlate bug records to real people ... with a bit of lateral thinking. And an exception logged in a bug record could include sensitive information like URLs, IP addresses, filenames, user names. This is a real privacy issue.
  • Even if we could mitigate all real privacy issues, this would still be perceived as a privacy issue by some people.
  • Something like this may have implications under European privacy law. We'd need to talk to a lawyer.

There are also a number of implementation issues. For instance:

  • implementing simple user opt-in / opt-out,
  • dealing with dynamically allocated IP addresses, NATed addresses, etc,
  • preventing bug logging from triggering further network related problems,
  • setting up and securing the bug reporting database, and
  • creating the tools that developers would use to analyse the reported bugs.

IMO, we don't need this now. We already have more JNode bug reports than we have the resources to deal with ... as you can see from the length of time that some of our "critical" issues stay open!

RE: Privacy

Submitted by tyhullinger on Thu, 05/21/2009 - 02:14.

What I mean by the exceptions being thrown is that in several portions of the code the error codes are being rid off(like trashing them).
For example:

public static void main(String[] args) throws Exception {

This portion of code catching these errors is vital to creating more reliable applications.

Although what you mention is very sensible there is a way to enable/disable this tracking.
Don't several Operating Systems include features to track bugs with the effort of keeping their personal information private?
Securing the database shouldn't be an issue nor securing it.

As with ip addresses there isn't a need to create a record of their ip address. Wouldn't it be feasible to make it optional to the user to track their machine's bug reports specifically? Have some terms that they must agree to before they are allowed to do so.

Responses

Submitted by Stephen Crawley on Thu, 05/21/2009 - 04:59. 
   public static void main(String[] args) throws Exception {

This portion of code catching these errors is vital to creating more reliable applications.

If you are saying that 'throws Exception' is a cause of unreliability, then the problem is with whoever codes their applications to use 'throws Exception' ... not with JNode per se. And, if the possibility of unwanted exception propagation worries you, the real solution is to use a static code analyser.

But actually, I'd dispute that "throws Exception" is always bad. You cannot equate "no uncaught exceptions" with reliable, especially since it is trivial to silently catch and ignore exceptions. In fact I argue that allowing unpredicted exceptions (e.g. ones that are not due to end-user error) to propagate to the shell level is actually a good thing. See JNode coding DOs and DONTs, in particular the bit where it says why "--debug" options are a bad idea. Indeed, your idea of logging uncaught exceptions to identify problems would be defeated if applications habitually caught exceptions they didn't know how to handle!!

Although what you mention is very sensible there is a way to enable/disable this tracking.
Don't several Operating Systems include features to track bugs with the effort of keeping their personal information private?
Securing the database shouldn't be an issue nor securing it.

As with ip addresses there isn't a need to create a record of their ip address. Wouldn't it be feasible to make it optional to the user to track their machine's bug reports specifically? Have some terms that they must agree to before they are allowed to do so.

Well yes, it is all possible and not particularly difficult from a technical standpoint. I never said otherwise! But it is a lot of work to implement a solution in a way that adequately deals with privacy and legal concerns. Bear in mind that we have to work under EU / German privacy law. This is a lot more strict that US law. Just asking the user to agree to some terms is not sufficient.

The bottom line is that we don't think it is worth the effort right now. When JNode has hundreds of developers and thousands of users, maybe the answer will be different.

Privacy concerns aside, the

Submitted by cluster on Thu, 05/21/2009 - 03:12.

Privacy concerns aside, the question still remains, of what use is this for JNode? It sounds to me like you are coming from the angle of an application that crashes. In such a case, it is the applications responsibility to make themselves more reliable, and handle such cases on their own. I have seen such reporting systems, and they generally have to worked into the application itself, rather than into the operating system, using some library that may link to a bugzilla or custom tracker.

Bottom line is, i dont think it is reasonable to expect JNode to provide bug tracker handling for other applications, there are libraries out there that can do this.

As for JNode itself, i dont support such a system within the operating system itself. Instead, it could be designed as an out-sourced plugin that could be installed/loaded for use by developers or those interested in testing/debugging.

But i think steve said it best, we have enough bugs, and the TODO list is quite long. Not to mention we don't exactly have a large user group. Until these things change, such a system isn't providing any real benefit.