Finding Bugs Is Easy 66
daveho writes "My advisor and I are working on a tool to automatically find bugs in Java programs. One of the interesting results of our work is that we've found hundreds of real bugs in production code using extremely simple techniques. We believe that automated tools, if used more widely, could prevent a lot of bugs from making it in to production systems."
History, repeat thyself. (Score:3, Insightful)
Automated tools like lint are an invaluable part of any software project and should be used at various points in a project's lifecycle. However, the bugs they find tend to be shallow (typecast problems, immediate memory violations, etc.). This is a certain improvement in software quality, but even Java programs can have side-effects from class to class that twist the mind of even the best programmer.
"Finding bugs is easy" makes sense in the context of my backyard but definitely not in programming.
Re:Reading UGH (Score:2, Insightful)
Re:Looks really kewl. (Score:3, Insightful)
Uninitialized read of labels in constructor:
// setlocale inits labels
if (labels == null){
setLocale(Locale.getDefault());
}
Its complaining because I'm comparing it to null? I think its a bug in the analysis.
Of course, it would be nice if there were a document that would tell you how to manipulate your code to hide things that you have determined not to be errors from the analyzer. Maybe a list of errors that you have already looked at. Possibly comments you can put in your code.
Re:History, repeat thyself. (Score:3, Insightful)
Halting (Score:3, Insightful)
Jason
ProfQuotes [profquotes.com]
Re:Halting (Score:3, Insightful)
Your statement is unnecessarily negative, unhelpful, and a bit silly.
Bank analogy not flawed (Score:2, Insightful)
I don't know which side of the autopsy/physician debugging argument I'd sit on. I quite like Matlab's approach (which I believe is similar to Lisp's), in that you can choose to enter debug mode when an error occurs, and you can then interactively probe you code to find out why it ended up in that state. This is particularly useful when you have (as I do) numerically-intensive code that might take several days to complete running -- you don't want to get to 3.9 days into a 4 day job and find out there was a bug in the very last command your code was to run without being able to figure out exactly why the error occurred -- the write-run-debug cycle would be very long indeed!
So, I can see the benefits of both approaches. I guess having a choice is important, and knowing when to opt for which flavour of error handling.