Slashdot Mirror
Open Source Programmers Stink At Error Handling
Mark Cappel writes: "LinuxWorld columnist Nick Petreley has a few choice words for for the open source community in 'Open source programmers stink at error handling'. Do you think commercial software handles errors better?"
Why does it seem like there are as many people in the "community" criticizing open source as there are supporting it?
Two Words: Apache and Tomcat
I'm a professional who works with the closed source equivalents all the time: Netscape iPlanet server, IIS and WebLogic.
Now: before you flame - I like working with WebLogic, but it is no better than Tomcat in my opinion (as far as error reporting goes). And IIS is a piece of crap! Not to mention Netscape's overly complecated UI that blasts every change you've ever made and is completely out of sync with the flat file configs.
Need I mention that Tomcat error logging is set-up in an XML file that is easy to read, modify, and translate into a simple report for management (IT that is).
When was the last time Windows gave you a nice error.log when it blue-screened, or how about IIS on a buffer overflow?
I'm sick of bashing on the free stuff out there. Sure, just because I can release one of my college projects into the open source may mean that statistically there are more projects without good error reporting, the real projects are pretty darn good.
I've been coding for over 20 years and I've seen some beauties, and I'm sure others have as well. Like the guy who put about 500 lines of Java in one Try - Catch. I'd suggest they screen their contributors better. Use a carrot and very gentle stick approach and be certain to encourage coders to think "what could happen here and how should I handle it?" whenever writing.
A feeling of having made the same mistake before: Deja Foobar
...is only as solid as the engineer behind it (and the design behind him/her). A poor design often results in a flaky system, difficult to implement and nearly impossible to predict. That, in turn, can result in very thin error handling. Whether or not a product is commercial has nothing to do with it. The only argument for that could possibly be that in many cases, more careful attention (in the form of testing and code reviews) is taken when a product is a revenue generator (or anything that will affect the perception of the quality of a company's engineering ability).
Ultimately, if the engineer (or team of engineers) is inexperienced, error-handling will be weak, error-recovery nearly non-existant. However, a more senior engineer will generally start from error handling on up, making sure the code is robust before diving too deeply into business logic. The time taken for unit testing plays an especially large role here. The more time spent trying to break the code (negative test cases) the more likely you will have a system that has been revised throughout development to have rock-solid error handling/reporting/recovery.
[McP]KAAOS
It goes from God, to Jerry, to me.
of handling errors that should never happen? You just double the size of your code, cause schedules to be missed, make maintenance more difficult and increase the probability of a grotesque coding error. I expected more macho stuff from the slashdot audience, not namby pamby whimpering! Sheesh! Welcome the the real world, get a thicker skin man!
8)
On a serious note : I've written commercial and non-commercial code. Sometimes I'm obsessive about completeness, sometimes I'm pragmatic. No point in generalizing about OSS vs. commercial.
Out of all open source software I use, my biggest complain is with Linux and how freaking hard it is to swap a hard drive to a new machine. I can only imagine the insults that will be thrown my way but 98, or even NT/2000 nine times out of 10 I will have no problem with this. Sure it takes about 30 minutes of clicking yes, install new hardware but it works (usually). Under Linux, can't load root fs, goto panic. Grr, that bugs me like nobodies business.
I am sure there is some semi-painful way to get around this but should I really have to? If you ask me, the kernel should not panic at this "error" and should recognize it, prompt you and try to solve it (probe the new hardware and load the correct module(s)). Maybe some distros are better than others (and I shouldn't be placing this "blame" on the kernel team).
Error messages need to have numbers associated with them. For instance when I have ORA-1241 in oracle, a quick search in groups.google.com will give me a lot of informations about this error, and why it occured and what I can do about. Alas, there is no such thing in most of Open Source software, you just have plain text, so the search is less effective, which search keywords are you going to choose. The situation is even worse for people who used localised versions of the software, as you don't have the English transltation so you can search the English archive in groups.google.com and which count for 80% of the posts.
What might be cool is a codified error numbering a la Oracle for instance. I would love to have KDE-2345 error, or GNOME-1234 error, or Koffice-567 etc. That would made searchs far more effectives
This is not about open-source vs closed-source programs, nor for-fun vs for-money programmers. It's about computational models such as von Neumann machines that, at their deepest roots, assume there will be no errors. That chain-of-falling-dominos style of thinking so permeates conventional programming on conventional machines that it's almost surprising that any code has any error handling at all.
Of course it's possible to hand-pack error-handling code all around the main functional code in an application.. and of course quality designers and programmers in and out of open-source will do just that.. but viewed honestly we must admit it's an huge drag having to do so, and typically fragile to boot, because the typical underlying computational and programming models provide no help with it. Error-handling code tends to be added on later to applications just as try/catch was added on later to C++.
Lest we think this sad state must be inevitable, let's recall that other computational models, like many neural network architectures for example, are inherently robust to low level noise and error. Then, that underlying assumption colors and shapes all the `programming' that gets built on top of it. We're to the point where trained neural networks, for all the limitations they currently have, can frequently do the right thing in the face of entirely novel and unanticipated combinations of inputs. Now that's error handling.
The saddest part is that von Neumann knew his namesake architecture was bogus in just this way, and expressed hope that future architectures would move toward more robust approaches. Fifty years later and pretty much the future's still waiting..
Error Handling and Appropriate Technology
This article is right on target. It's much more important for open source software to be of a higher standard than closed-source, simply because with open source, shoddiness can't be hidden and swept under the carpet (to state the bleedin obvious). If we make shoddy open-source code, then up-and-coming programmers will see it, learn from it, and treat this very ordinary code as the 'norm'. Worse, they will treat it as a target to be aimed for, and cut corners so even this low standard isn't met.
FWIW I've worked in safety-critical areas for some 20 years. I've managed to dodge being assigned to management, and am doing neat stuff like spaceflight avionics for interest rather than chasing dollars doing yet-another-b-2-b system. The biggest problem I've found with re-educating interns is getting them to be paranoid enough. It's a matter of culture.
Quick N Dirty is an appropriate culture for some systems.
If you're writing throwaway code for a specific purpose (such as a simple script) then quality isn't an important issue.
If a deadline is approaching fast, your budget is zero, your team burnt out, then damn the long-term costs, hack it so it kinda works and ship it on time. It's crap, but they only paid for less than crap, so don't worry, be happy.
There's a major financial incentive to write high-maintenance code, both for programmers and companies. You make pennies on the initial sale, megabucks on the maintenance. What do you call a programmer who writes superb code that's maintenance-free? Unemployed.
This is true for design and requirement analysis, as well as code.
But... it's important to realise this is not the only way of doing things. It has it's place. But not in open source.(And there's such a thing as professional pride too, but I digress)
If you're writing a re-useable module, you should treat all inputs as being guilty until proven innocent, always check any outputs from your area, and be honest regarding what side-effects your module has. In some languages, this is easy (e.g. Ada ), in others darn near impossible (e.g. C), but it has to be done. It's obvious that you have to do it when lives are at stake. It's less obvious when you're writing some device driver for Linux - but literally tens of billions of dollars may be riding on how well you do your job. Even if you're not getting paid for it.
I'm not asking for the degree of robustness typically shown by safety-critical systems What? Your code failed just because half the memory was corrupted and a CPU was on fire? Unacceptable! Failure is Not an Option! but enough so that BSODs or their equivalent lead to puzzlement I've never seen one of those before!.
Zoe Brain - Rocket Scientist
I expect that it is true that commercial software does a generally better job than open source software at error handling. This is probably even measurable: run comparable software products under similar usage load, and collect the errors generated (reported or experienced by users). I haven't tried such an experiment myself.
I don't why we (we = open source enthusiasts) should feel particularly worried about it at the moment. For most applications, the commercial alternative has a vastly larger user base than the open-source equivalent. And since these users are paying for their software, they are going to expect that there is a vendor who will respond to their concerns.
Customer service operations are very expensive. So it is very much in the interest of the commercial vendor to reduce the error rate to the level where the load on customer service is financially tolerable (this is not the same as zero).
Fixing obscure bugs is not the most exciting technical endeavor, and skilled engineers are more willing to do this work if you pay them...
As I said, I don't think we should feel bad about this state of affairs. A more appropriate line of discussion would be: What can the open source community do to create an environment where a higher degree of quality is met consistently for open source software products? Are there tools that we could build that will help? Non-intrusive processes that we can impose on one another? The Perl community in particular has an effort underway to establish a consistent level of testing for all the modules that are released on CPAN. Is that a worthwhile model?
to bugs. Bugless programs don't need error checking, just input bounds checking. Use Lisp and prove your program with mathmatical induction, or optionally, you can keep the same mindset in C. Just don't let the user screw up. If you have a finite set of inputs, you can very easily see that your program won't fail. I find it much easier to create functions to test that certain things work as expected than putting try blocks around things.
:)
:)
:) It's not laziness... just tired, and you aren't really getting paid for the work, so why try as hard as you do for paid work? I'm not even metioning games which I believe are essential. All programmers need to take their frustrations out on some helpless AI creature, or else they would buckle under the stress.
Now that I've given all the tips that I'm aware of, its time for the justification of my own faulty behavior that can't be justified
I think open source software does well for bug handling though. The bigest things I can think of that a lot of open source projects have faults with were never meant to be mission critical || are v1.0 || miss coordination caused some negative synergey. As for the first two, you should expect failures. The last is going to happen to even the best. I think it is a testament to OSS still. With such little time to invest, all the products I've seen get better every day.
And here come the excuses...
I really wouldn't call it laziness, but more a lack of motivation. The bulk of OSS is written in a geeks spare time, which in itself is small if the geek attends college and works. You have to account for all the reading a geek has to do on a daily basis. (Slashdot, Freshmeat, Changelogs, Anandtech et al, Pricewatch & EBay) Then account for all the time A geek spends perfecting his own system. (New kernel, apt-get, compiling his special favorite programs(MySQL, Apache, PostgreSQL, XBill)) By the time you get done with all the things you try to stay on top, you really don't have much time left. From there on out, your sleepy and are working purely on caffiene. You will enevitably make a few mistakes.
Before someone says it, I know the rewards of OSS programming. If there were no rewards, then no one would do it in the first place.
Karma Clown
I'm astonished at the poor error-handling in most software these days.
The biggest problem is not whether your language has exceptions (good error-handling has been done for years without them) or whether programmers are lazy. It's a matter of making it a priority. In fact, laziness caused a lot of us old-timers to take a major interest in error-handling.
Picture the days before internet access, running mainframe systems, probably with overnight batch cycles.
Good error handling might mean that you don't get a phone call at 3:00 am.
If that phone call comes, good error messages might mean that you can diagnose the problem over the phone and walk the operator through recovery.
In either case, you don't have to drive down to the data center.
Sleep. Now there's a motivator.
...but the same is equally true of the vast majority fo commercial and closed source programs too. The sad fact is that jobs like reducing the number of warnings from the compiler and testing can be incredibly boring jobs that noone wants to do, so NoOne does it except in the most perfunctory manner.
Its been said that a lot of open source development projects ought to have some form of Audit person or team whose job it is to look at the project code and then when they find problems to go and reeducate the person who wrote the faulty code, preferably teaching him not to do it again [with a large hammer if necessary!]
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon