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?"
Yes.
But not for the reasons everyone normally thinks.
pirst prost
agreed, bad error handling.
Linus' changes to 2.4.10,2.4.11 were improvments
to error handling. Open source developers might
not be to good at this, but at least in the nature
of open source it is found and corrected.
We really need this open source BSOD library
that would make our life more convenient and
our applications more commercial-like.
If programs would be read like poetry, most programmers would be Vogons.
Seconds after the story was posted, LinuxWorld is already gone... :-p
You mean, that exists?
There are some good pieces of Open Source software out there, sure, but most of it isn't all that great. Shit shouldn't crash when a directory it's been stat()ing suddenly no longer exists or its config file hasn't been created yet. Lots of Open Source software does that, though.
Who spend days at a time at work (read: Stallman) without showers, removing the last 3 words provides a better description :o)
Things like checking pointers to see if they are NULL before using them. Simple basic things that could prevent errors.
Error handling doesn't just mean catching the error after its already happened. It also means being proactive about it before it happens.
A lot of programmers do not do that.
Visit the Arcade Restoration Workshop @ http://www.arcaderestoration.com
Error handling is much less important when the frequency of errors is so low with in our community. Error handling is even less importnat when the results of errors don't cause things like BSODs, GPFs or icons with frowning faces.M$ and others need to be more concerned with error handling because it's a much more common occurance in the closed source world.
What are these "errors" you speak of? Open source has no errors...
That's the error I'm getting. Could it possibly be slashdotted in only 3 minutes?
Too bad, I was hoping I could say something meaningful, or maybe even relevant...
Under capitalism man exploits man. Under communism it's the other way around.
When I tried to access the story I got an error message:
/site-stories/2001/1025.errorhandling.html.
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET
Reason: Could not connect to remote machine: Connection refused
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Buy Hex-Rated Stuff, fight the DMCA!
Its plain and simple. Look at how professionally IE handles bugs. It redirects the user to a page which leads them into believing the browser isnt to blame.
Mozilla on the other hand takes all the flak for itself and blames itself for other's problems.
Duh!
-- If you try to fail and succeed, which have you done? - Uli's moose
it's a feature.
"I may not have morals, but I have standards."
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.
My textbook example:
It takes no argument, and only produces one line of output. Despite this apparent simplicity, I've been able to get each and every pwd that ships with a commercial Unix to dump core (almost always by executing in an exceedingly deep directory.)
The GNU shellutils version of pwd, on the other hand, has never dumped core on me.
I will admit, the fact that it took two decades for a non-crashable version of pwd to become available doesn't bode well for the many other vastly more complicated programs out there in any environment. But it does speak very highly of the GNU utilities in general, and I haven't even begun to praise the thousands of folks who have worked on making these tools quite portable!
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
The real problem, IMHO, is that nobody likes to do the intensive testing that is necessary to get a program to be truly robust. We do it here at IBM, and I promise you -- it's not something I would do if I weren't being paid to do it.
Taral
WARN_(accel)("msg null; should hang here to be win compatible\n");
-- WINE source code
Since LinuxWorld seems to be /.ed already, here's the story:
Open source programmers stink at error handling
Commercial programmers stink at it too, but that's not the point. We should be better.
Summary
Why are we subjected to so many errors? Shouldn't open source be better at this than commercial software? Where are the obsessive-compulsive programmers? Plus, more reader PHP tips. (1,400 words) By Nicholas Petreley
(LinuxWorld) -- Thanks to my very talented readers I've been able to start almost every recent column with a reader's PHP tip. I'm tempted to make it a regular feature, but with my luck the tips would stop rolling in the moment I made it official. So I want you to be aware that this week's tip is not part of any regular practice. It is purely coincidental that PHP tips appear in column after column. Now that I've jinx-proofed the column, I'll share the tip.
Reader Michael Anderson wrote in with an alternative to using arrays to pass database information to PHP functions. As you may recall from the column Even more stupid PHP tricks, you can retrieve the results of a query into an array and pass that array to a function this way:
Michael pointed out that you can also retrieve the data as an object and reference the fields as the object's properties. Here's the above example rewritten to use objects:
name;
echo $CUST->address;
}
?>
I can't help but agree with Michael that this is a preferable way to handle the data, but only because it feels more natural to me to point to an object property than to reference an element of an array using the string name or address. It's purely a personal preference, probably stemming from habits I learned using C++.
OCD programmers unite
Nothing could be a better segue into the topic I had planned for this week. I'm thinking about starting a group called OLUG, the Obsessive Linux User Group. Although I know enough about psychology to know I don't meet the qualifications of a person with full-fledged OCD (Obsessive-Compulsive Disorder), I confess that I went back and rewrote my PHP code to use objects instead of arrays even there was no technical justification for doing so.
Certain things bring out the OCD in me. Warning messages, for example. It doesn't matter if my programs seem to work perfectly. If a compiler issues warnings when I compile my code, I feel compelled to fix the code to get rid of the warnings even if I know the code works fine. Likewise, if my program generates warnings or error messages at run time, I feel driven to look for the reasons and get rid of them.
Now I don't want you to get the wrong impression. My PHP and C++ code stand as testimony to the fact that my programming practices don't even come within light years of perfection. But just because I do not live up to the standards I am about to demand isn't going to stop me from demanding them. It's my right as a columnist. Those who can, do. Those who can't, write columns.
I'll be blunt. Open source programmers need to stop being so darned lazy about error handling. That obviously doesn't include all open source programmers. You know who you are.
If you want a demonstration of what I mean, start your favorite GUI-based open source applications from the command line of an X terminal instead of a menu or icon. In most cases this will cause the errors and warnings that the application generates to appear in the terminal window where you started it. (There are exceptions, depending on the application or the script that launches the application.)
Many of the applications I use on a daily basis generate anywhere from a few warnings or error messages to a few hundred. And I'm not just talking about the debug messages that programmers use to track what a program is doing. I mean warning messages about missing files, missing objects, null pointers, and worse.
These messages raise several questions. Doesn't anyone who works on these programs check for such things? Why do they go unfixed for so long? Are these problems something that should be of concern to users? Worse, what if these messages appear because of a problem with my installation or configuration, and not because the program hasn't been fully debugged? But even if it is my installation that is broken, shouldn't the application report the errors? Why do I have to start the application from a terminal window to see the messages?
Getting a handle on errors
At first I wondered if this was a problem that you would be more likely to find when developers use one graphical toolkit rather than another. But I see both good and bad error handling no matter which tools people use. For example, the GNOME/Gtk word processor AbiWord has been flawless lately. Not a single warning or error message appears in the console. It's possible that AbiWord simply isn't directing output to the console, but I'm guessing that it's simply a well-tested and well-behaved application.
On the other hand, GNOME itself has been a nightmare for me lately. At one point I got so frustrated that I deleted all the configuration files for all of GNOME and GTK applications in my home directory in disgust, determined never to use them again. When I regained my composure and restarted GNOME with the intent of finding the cause of the problems, the problems had already disappeared. Obviously one or more of my configuration files had been at fault. Which one, I may never know, because GNOME or some portion of it lacked the proper error handling that should have told me.
In this case I was lucky that the problems were so bad I lost my temper and deleted the configuration files. In most cases, the applications appear to function normally. Aside from being ignorant of any messages unless you start the application from a terminal, there's no way of knowing why the warnings exist, or if they are cause for concern. The warnings could be harmless, or they could mean the application will eventually crash, corrupt data, or worse.
Examples
Just so you know I'm not making this up, here are some samples of the console messages that appeared after just a couple of minutes of toying with various programs. By the way, did you know you can actually configure the Linux kernel from the KDE control panel? Bravo to whoever added this feature. Nevertheless, when I activate that portion of the control panel, I get the message:
QToolBar::QToolBar main window cannot be 0.
Is there supposed to be a toolbar that isn't displayed as a result? I may never know.
The e-mail client sylpheed generates this informative message after about a minute of use:
Sylpheed-CRITICAL **: file main.c: line 346 (get_queued_message_num): assertion `queue != NULL' failed.
The Ximian Evolution program generates tons of warnings, but most are repetitions. They begin with the following:
evolution-shell-WARNING **: Cannot activate Evolution component -- OAFIID:GNOME_Evolution_Calendar_ShellComponent
evolution-shell-WARNING **: e_folder_type_registry_get_icon_for_type() -- Unknown type `calendar'
evolution-shell-WARNING **: e_folder_type_registry_get_icon_for_type() -- Unknown type `tasks'
The KDE Aethera client generates even more warning messages than Evolution, but many of them are simply debug messages about what the program is doing. By the way, I finally figured out why I couldn't login to my IMAP server with Aethera. The Aethera client couldn't deal with the asterisks in my password. I could log in after I changed my password, but I still can't see my mail. The program simply leaves the folder empty and says there's nothing to sync. Here are just a few of the countless warnings I get from Aethera, including the sync message.
Warning: ClientVFS::_fact_ref could not create object vfolderattribute:/Magellan/Mail/default.fattr
Reason(s): -- object does not exist on server
Warning: VFolder *_new() was called on an already registered path
clientvfs: warning: could not create folder [spath:imap_00141, type:imap]
RemoteMailFolder::sync() : Nothing to sync!
The spreadsheet Kspread reports these errors all the time, even though what I'm doing has nothing to do with dates or times:
QTime::setHMS Invalid time -1:-1:-1.000
QDate::setYMD: Invalid date -001/-1/-1
The e-mail client Balsa popped up these messages just moments after using it:
changing server settings for '' ((nil))
** WARNING **: Cannot find expected file "gnome-multipart-mixed.png" (spliced with "pixmaps") with no extra prefixes
The Gnumeric spreadsheet only reported that it couldn't find the help file, as shown below:
Bonobo-WARNING **: Could not open help topics file NULL for app gnumeric
Many of these problems could easily have been handled more intelligently. For example, Gnumeric could have asked for the correct path to the help file, perhaps adding an option so a user can decide not to install the help files and disable the message. Unless GTK and Bonobo are a lot more complicated than they should be, it should be easy to create a generic component for handling things like this and then use the component to handle all optional help files as a rule.
The only conclusion I can draw is that, like most commercial software developers, many open source programmers are just plain lazy about proper error handling. But we're supposed to be better than that, and it's time we started to live up to the reputation. I realize that most of these programs are works in progress. But good error handling is not something that should be left for last. It should be part of the development process. Although I may not practice it myself, I'm not the least bit ashamed to preach it.
"It take 9 months to bear a child, no matter how many women you assign to the job."
As a professional programmer I adhere to a strict stylesheet which I think the Open Source community may appreciate a copy of:
main( arguments ){
try{
--code goes here--
}catch( exception ){
printout "I'm sorry to do that you need our $50k/year support plan. \n Thank you!"
}}
No need to thank me.
There is no substitute for a good ol' BSOD.
...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.
Petreley writes:
The only conclusion I can draw is that, like most commercial software developers, many open source
programmers are just plain lazy about proper error handling. But we're supposed to be better than that...
Doing good error / exception handling is tedious, requires hard thought, and is nowhere near as fun as writing the mainline code. It requires a lot of discipline to first sit down and think through an exception-handling policy, to stick with it while coding, and then to audit the code and ensure that everything sticks to it.
Lots of commercial projects, in the rush to get out the door, skip all the above, or some. Open source projects may or may not have the philosophy worked out, let alone the discipline.
I guess we need a small army of exception-handling drill sergeants looking over code and yelling "YOU CALL THAT ERROR HANDLING? MY GRANNY DOES BETTER ERROR HANDLING THAN THAT..."
horribly truncated sig:
You just gotta write software without any errors. Every good open-source programmer knows this.
(j/k)
No way! Who'd stand for that?!?!
---
Information wants...you to shut your pie hole.
For instance, I know many "average" users who eject floppy disks and CD-ROMs from the drive while they are being read. Any Linux user who tries a stunt like that deserves a seg fault (or worse). The more error-handling and anti-stupidity measures that are added to a piece of software, the less versatile that software is. Flexibility comes at the expense of simplicity, and lesser users do not deserve the rich functionality that open source has to offer if they do not know how to handle themselves with a computer.
-CT
which is why Open Source is required. So we can all see exactly where the code stinks and we can fix it. Too bad legacy development models don't provide such advantages. Wouldn't it be cool if you could just buy quality software?
------DO NOT WRITE BELOW THIS LINE------
Ok, this article is not negative towards open source programmers, but to programmers as a whole. This guy has the nuts to say that most programmers don't handle error conditions very gracefully.
Unfortunately he is correct. There are a great deal of programmers that just do not know what they are doing. That's life though, and that's also why the goods ones get paid so well...
So lets encourage bad programmers to write lots of bugs so that the good programmers can get paid lots of money to be on tiger teams to fix the high priority problems introduced by the moron developers.
int func(int a);
func((b += 3, b));
I am a commercial programmer and in general unless
it is a critical section of code I am yet to meet
a programmer who does do all the checks they should. I know I never do. I think it has to do with out belief that "ahh that will never happen"
which of course it always does =o). I do however
think the OS software gets better tested and as a
result the error checks will eventually get put in or the errors will go away and the will not happen.
Hettar.
Real programmers....
;)
OR
Error handling.. nah.. no stupid users entering monkeydata couldn't install this...
/K
I've found that most open source software that is pre- release1.0 does do a shoddy job of handling error. But then again so does every piece of beta-test commercial software I've ever seen. Most of the better written open source software I've used that has reached version 1.0 does handle errors well. Look at programs like the GIMP, OpenOffice, Apache and vim. They all do a good job with errors -- you know what went wrong and usually why.
- 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?"
Does he have any choice words for for lack of proofreading? (note also the unclosed double-quote)I/O Error G-17: Aborting Installation
I was just re-re-reauthenticating my Cubase installation. The key CD is now scratched which hangs the authenticator forced a quite ungraceful reboot and corrupted my hard drive. (Perhaps a $150 upgrade will help. I'll never know.)
The last time I used Word a drive filled during a save operation and left me with just a mutilated copy of the original file. (I will not use it again.)
My HP PSC 750xi software informs me every morning that its controlling software was exploded and I should reboot the host computer. (I'll wait for the OS-X drivers. If they are still bad the PSC goes out the door.)
The most amazing part is that this state of affairs doesn't surprise me. If my refrigerator intermittently defrosted and melted icecream all over the kitchen I'd be ticked. If my car mysteriously dies at stop signs I get it fixed.
Programmers have managed to beat down everyone's expectations to the point where half-assed is pretty good.
The only way I see to fix it is for consumers to refuse to buy flawed products, or legislators to pass laws allowing redress for flawed products.
I don't think either is likely.
I now use OSS for my mission critical work and fix what needs it.
Commmercial: "This program has performed an illegal operation...
Open Source: "Segmentation fault. core dump.
Ciao
nahtanoj
"Do you think commercial software handles errors better?"
What's that got to do with it? Either its right or it's not, regardless what commercial software does.
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.
I guess if /. killed the site, it should mirror it :)
Here is a select-n-middlemousebuttonclick(with my formatting):
Title: Open source programmers stink at error handling.
Outline: Commercial programmers stink at it too, but that's not the point. We should be better.
Summary: Why are we subjected to so many errors? Shouldn't open source be better at this than commercial software? Where are the obsessive-compulsive programmers? Plus, more reader PHP tips. (1,400 words)
Author: By Nicholas Petreley
Body: (LinuxWorld) -- Thanks to my very talented readers I've been able to start almost every recent column with a reader's PHP tip.I'm tempted to make it a regular feature, but with my luck the tips would stop rolling in the moment I made it official.So I want you to be aware that this week's tip is not part of any regular practice. It is purely coincidental that PHP tips appear in column after column. Now that I've jinx-proofed the column, I'll share the tip.
Reader Michael Anderson wrote in with an alternative to using arrays to pass database information to PHP functions. As you may recall from the column Even more stupid PHP tricks, you can retrieve the results of a query into an array and pass that array to a function this way:
<?PHP
$result = mysql_query("select name, address from customer where cid=1");
$CUST = mysql_fetch_array($result);
do_something($CUST);
function do_something($CUST) {
echo $CUST["name"];
echo $CUST["address"];
}
?>
Michael pointed out that you can also retrieve the data as an object and reference the fields as the object's properties. Here's the above example rewritten to use objects:
<?PHP
$result = mysql_query("select name, address from customer where cid=1");
$CUST = mysql_fetch_object($result);
do_something($CUST);
function do_something($CUST) {
echo $CUST->name;
echo $CUST->address;
}
?>
I can't help but agree with Michael that this is a preferable way to handle the data, but only because it feels more natural to me to point to an object property than to reference an element of an array using the string name or address. It's purely a personal preference, probably stemming from habits I learned using C++.
Subtitle: OCD programmers unite
Nothing could be a better segue into the topic I had planned for this week. I'm thinking about starting a group called OLUG, the Obsessive Linux User Group. Although I know enough about psychology to know I don't meet the qualifications of a person with full-fledged OCD (Obsessive-Compulsive Disorder), I confess that I went back and rewrote my PHP code to use objects instead of arrays even there was no technical justification for doing so.
Certain things bring out the OCD in me. Warning messages, for example. It doesn't matter if my programs seem to work perfectly. If a compiler issues warnings when I compile my code, I feel compelled to fix the code to get rid of the warnings even if I know the code works fine. Likewise, if my program generates warnings or error messages at run time, I feel driven to look for the reasons and get rid of them.
Now I don't want you to get the wrong impression. My PHP and C++ code stand as testimony to the fact that my programming practices don't even come within light years of perfection. But just because I do not live up to the standards I am about to demand isn't going to stop me from demanding them. It's my right as a columnist. Those who can, do. Those who can't, write columns.
I'll be blunt. Open source programmers need to stop being so darned lazy about error handling. That obviously doesn't include all open source programmers. You know who you are.
If you want a demonstration of what I mean, start your favorite GUI-based open source applications from the command line of an X terminal instead of a menu or icon. In most cases this will cause the errors and warnings that the application generates to appear in the terminal window where you started it. (There are exceptions, depending on the application or the script that launches the application.)
Many of the applications I use on a daily basis generate anywhere from a few warnings or error messages to a few hundred. And I'm not just talking about the debug messages that programmers use to track what a program is doing. I mean warning messages about missing files, missing objects, null pointers, and worse.
These messages raise several questions. Doesn't anyone who works on these programs check for such things?Why do they go unfixed for so long? Are these problems something that should be of concern to users?Worse, what if these messages appear because of a problem with my installation or configuration, and not because the program hasn't been fully debugged?But even if it is my installation that is broken, shouldn't the application report the errors? Why do I have to start the application from a terminal window to see the messages?
Subtitle: Getting a handle on errors
At first I wondered if this was a problem that you would be more likely to find when developers use one graphical toolkit rather than another. But I see both good and bad error handling no matter which tools people use. For example, the GNOME/Gtk word processor AbiWord has been flawless lately. Not a single warning or error message appears in the console. It's possible that AbiWord simply isn't directing output to the console, but I'm guessing that it's simply a well-tested and well-behaved application.
On the other hand, GNOME itself has been a nightmare for me lately. At one point I got so frustrated that I deleted all the configuration files for all of GNOME and GTK applications in my home directory in disgust, determined never to use them again. When I regained my composure and restarted GNOME with the intent of finding the cause of the problems, the problems had already disappeared. Obviously one or more of my configuration files had been at fault. Which one, I may never know, because GNOME or some portion of it lacked the proper error handling that should have told me.
In this case I was lucky that the problems were so bad I lost my temper and deleted the configuration files. In most cases, the applications appear to function normally. Aside from being ignorant of any messages unless you start the application from a terminal, there's no way of knowing why the warnings exist, or if they are cause for concern. The warnings could be harmless, or they could mean the application will eventually crash, corrupt data, or worse.
Subtitle: Examples
Just so you know I'm not making this up, here are some samples of the console messages that appeared after just a couple of minutes of toying with various programs. By the way, did you know you can actually configure the Linux kernel from the KDE control panel? Bravo to whoever added this feature. Nevertheless, when I activate that portion of the control panel, I get the message:
QToolBar::QToolBar main window cannot be 0.
Is there supposed to be a toolbar that isn't displayed as a result? I may never know.
The e-mail client sylpheed generates this informative message after about a minute of use:
Sylpheed-CRITICAL **: file main.c: line 346 (get_queued_message_num): assertion `queue != NULL' failed.
The Ximian Evolution program generates tons of warnings, but most are repetitions. They begin with the following:
evolution-shell-WARNING **: Cannot activate Evolution component -- OAFIID:GNOME_Evolution_Calendar_ShellComponent
evolution-shell-WARNING **: e_folder_type_registry_get_icon_for_type() -- Unknown type `calendar'
evolution-shell-WARNING **: e_folder_type_registry_get_icon_for_type() -- Unknown type `tasks'
The KDE Aethera client generates even more warning messages than Evolution, but many of them are simply debug messages about what the program is doing. By the way, I finally figured out why I couldn't login to my IMAP server with Aethera. The Aethera client couldn't deal with the asterisks in my password. I could log in after I changed my password, but I still can't see my mail. The program simply leaves the folder empty and says there's nothing to sync. Here are just a few of the countless warnings I get from Aethera, including the sync message.
Warning: ClientVFS::_fact_ref could not create object vfolderattribute:/Magellan/Mail/default.fattr
Reason(s): -- object does not exist on server
Warning: VFolder *_new() was called on an already registered path
clientvfs: warning: could not create folder [spath:imap_00141, type:imap]
RemoteMailFolder::sync() : Nothing to sync!
The spreadsheet Kspread reports these errors all the time, even though what I'm doing has nothing to do with dates or times:
QTime::setHMS Invalid time -1:-1:-1.000
QDate::setYMD: Invalid date -001/-1/-1
The e-mail client Balsa popped up these messages just moments after using it:
changing server settings for '' ((nil))
** WARNING **: Cannot find expected file "gnome-multipart-mixed.png" (spliced with "pixmaps") with no extra prefixes
The Gnumeric spreadsheet only reported that it couldn't find the help file, as shown below:
Bonobo-WARNING **: Could not open help topics file NULL for app gnumeric
Many of these problems could easily have been handled more intelligently. For example, Gnumeric could have asked for the correct path to the help file, perhaps adding an option so a user can decide not to install the help files and disable the message. Unless GTK and Bonobo are a lot more complicated than they should be, it should be easy to create a generic component for handling things like this and then use the component to handle all optional help files as a rule.
The only conclusion I can draw is that, like most commercial software developers, many open source programmers are just plain lazy about proper error handling. But we're supposed to be better than that, and it's time we started to live up to the reputation. I realize that most of these programs are works in progress. But good error handling is not something that should be left for last. It should be part of the development process. Although I may not practice it myself, I'm not the least bit ashamed to preach it.
Leonid Mamtchenkov
Nick Petreley is a moron. Intelligent people don't make blanket statements like "Open source programmers stink at error handling." Next thing you know, he'll be telling you "Closed source programmers use more descriptive variables." How the hell does he know?
Programming traits - just like preferences for pizza toppings, frequency in bathing and type of pr0n - vary from programmer to programmer. Some implement proper error handling, others could care less. It doesn't matter whether they're working on an open or closed source project. If the open-source programmers all traded places with the closed-source programmers, you'd have the same ratios of proper vs. improper error handling (although the traffic from open-source-programmers.com to goatse.cx would probably spike).
-Ryan, with the unoriginal sig
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).
I always have inaccessible boot device bluescreening problems under 2000. 98 does happily accept the other drive, but win2k seems to get far angrier. Perhaps I am missing something?
What we call folk wisdom is often no more than a kind of expedient stupidity.-Edward Abbey
Slashdotted already? Guess that's what you
get for running a www server on Linux. If only
the used a BSD instead.
Over the past few years I've used several OSS programs in pre-release versions, and the tendency I observed was for the programmers to provide "last gasp" file saves to keep you from using work when the program crashed. For instance, I never lost a keystroke when using early versions of LyX.
I don't recall ever seeing this in a commercial product, though I haven't used any commercial products to speak of lately, so perhaps the state of the art has changed. I sure used to lose a lot of work under commercial software, though.
Sheesh, evil *and* a jerk. -- Jade
Anyway, he's got the source, why not fix it.
See my .sig for linkage!
If you celebrate Xmas, befriend me (538
At HAL earlier this year Hugh Daniels said pretty much the same thing. For those who don't know, hugh Daniel is the guy who heads up the FreeS/WAN project. Anyway, his basic take on the situation is that error handling is what is placed in that last 10% of the famous 90/10 split.
;-)
You know, getting it to work roughly is 90% of the job, and can be done in 50% of the time. Getting it to work properly all of the time is the last 10% and that takes the last 50%.
The problem as I see it is that all too often open source software is created to "scratch an itch". When used "according to the instructions", or as the original author used it, it will normally work OK. It is only once you get into the realms of unorthodox usage that it causes problems.
Hmm. Sounds like microsoft!
Anyway, it is not endemic to either open or closed source, but it is endemic to under resourced projects. I have worked on commercial projects where every i was dotted, and every t was crossed. i have also worked on projecls where lhis was nol lhe case.... The primary difference between the two was the amount of time that i was given.
The very same holds true for open source. The bigger projects with more developers, ie. samba, gimp, the kernel(s), tend to be quite good. the smaller projects, ie. psinfo, ls, tend to be quite good. But often when you get between those two it is a whole different kettle of fish.
BTW. Hugh Daniel did not only complain about lack of error handling, but also the poor quality of error handling. And this is endemic. Basically this boiled down to "OK, so something is wrong, why havne't you told me possible ways to fix this?"
I just can't handle errors! That's why I use linux instead of windows!
------- I saw a VW Beatle the other day. The vanity Plates said "FEATURE"
As for IIS, that buffer overflow you mention is "completely theoretical", and consequently I don't think IIS has any reporting of this type.
Sometimes a picture is worth 1000 words. Or 1000 slashdot posts.
It seems a lot of open source programs do in fact have little error handling. Most open source programs seem to focus on functionality, rather than usability. It gets you from point A to point B, and doesn't give you much help in between. If the user is not a master programmer, any errors usually end up being cryptic and nonsensical. It seems that a lot of commercial software has decent error recovery, and prevents user error effectively. Now I know there are many exceptions, but I think it simply has to do with the fact that commercial programmers get paid to do their work, and competition forces companies to put out products that are competitively usable.
Seriously, I once booted a Macintosh and the only thing that came on the screen was a little "Sad Macintosh." Apparently means that your system folder is corrupt. How's that for error handling?
Want to see more? Try this Mac troubleshooting guide. [yale.edu]
Programmers stink at error handling. Most programmers stink at prgramming, for that matter, and error handling in particular is something that people give little attention to. It takes a lot of expereince and effort to develop good error-handling discipline.
Exceptions are mandatory for good programming, period. If the language you are using doesn't support exceptions (C, Perl, etc), you are going to have problems. Exceptions make sure that if an error occurs, and you aren't aware of it, your program dies, and doesn't go on its merry way, causing a security hole/unstable software.
Perl's hack at exceptions using 'die' doesn't cut it; one important thing about implementing exceptions is that your base operations (e.g., opening files, and other system functions) need to raise exceptions when problems occur. If this doesn't happen, you're only going to struggle in vain to implement good, correct code.
Exceptions are a primary reason I've moved from Perl to Python. Python's exceptions model is standard and clean. Base operations throw exceptions when they occur problems. And my hashes no longer auto-vivify on access, thank goodness. Auto-vivification on hash access are probably one of the principle causes of bad Perl code.
When you start Outlook Express, it often displays the password entry box before it has finished drawing the screen. Enter your password before the redraw has finished and Lookout locks up. (Netscape 4.7x has a similar problem, too.)
Most languages make error checking very hard. In particular, C and Perl, two of the most used langs in OSS development, lack good mechanisms for sane error checking. I might explain more, but is better explained at this document.
btw, the document is part of a library that allows nicer error checking in C, called BetterC. (Yes, this is a plug, I've participated in the development).
It is modelled in Eiffel's "Design by contract", a set of techniques complemented with language support to make error checking a lot easier and semiautomatic. "Design by contract" has been described as "one of the most useful non-used engineering tool".
The open source community should take the same stance as closed source corporations when it comes to bugs. They are not really bugs but undocumented features!
Strange women lying in ponds distributing swords is no basis for a system of government.
One of the problems is that when people learn to code in college they are not encouraged to do error checking. I can understand why this is so. I once turned in a simple program that was on average a page to a page and a half of code (c++). I went back later to have some kind of mechanism (this was before I knew about try Ccatch circa 1995) that would catch people from inputting the wrong type and locking things up because of the error flag being set (if they did I re-set the bit and had them input again). Plus other things like other runtime errors and the like (divide by zero errors were always required to be checked). This took as much time as writing the original assignment and almost added a page of code (maybe a half page J ). The point is it wasnt required. Just the other day, (Im A Grad student now) I over heard a student tell a TA But the professor said we dont have to check if the input is valid he said assume it is.± Colleges and universities have gotten a lot better about documentation and the like, but much improvement needs to be done in getting people to catch runtime errors in their programs (especially c, c++, and java but java in some ways forces it upon you). The problem is the time factor that is involved. Im not sure I have the answer to that. Except I know that when you learn bad habits they tend to stay with you. It took me personally a long time to learn to document BEFORE (design) and during coding, but through discipline I changed my ways. If Professors forced people from the start to do such things(as in error checking) then when the projects got bigger maybe it wouldnt be so bad. And in so doing maybe it would filter into real world projects that people always consider error checking.
Then again maybe not.
And I would be careful about holding up Tomcat as an (open source) triumph. It's had some major bugs all through the 3.x timeframe, and its team includes at least a few daytime profressional "closed source" programmers (there's no correlation between the two, by the way).
The only certainty is entropy.
I believe the number of error can be reduced with code reviews. This site can help you get reviews :)
In my experience, applications with a big focus on usability tend to have better error handling on multiple levels, the first being more of it; the second being better explainations of errors that do occur.
Given that most open-source software doesn't have a big focus on usability, I think it's obvious that open-source applications will be perceived as having poor error handling.
...is that open-source software tends to ship with error messages turned on. Closed-source software often generates no fewer errors, but it tends to ship with error messages compiled out.
I would venture to say that a mature open-source project probably has better error handling than a corresponding mature closed-source project, simply because in the closed-source projects I've worked on have always had tight schedules and we've rarely had time to go back and clean up all those last bugs, no matter how major. It was "good enough" and it shipped, time to move on.
OSS developers can do that, and I think it generally leads to better software in the long run.
I'm starting an OSS project and I decided as one of the first things I would do would be to check the return value/status of every function call, and any of the functions that I wrote would use the return value as an error indicator.
I also wanted to assign each instance that an error, fatal or not, a unique error number that could be looked up on a website. One the website would have a description of what was happening that might have caused that error, and some suggestions to try. Perhaps I could add a place where users could submit comments to that.
I'm told that is similar to what Oracle does? I think realplayer does something similar, except when I click the link for more information 100% of the time I get a webpage that says "This error doesn't happen that often so we don't have anything to say about it" which I take to mean, "We don't know what the hell happened either"
Have any readers tried anything like this that has worked?
Yeah? My code might not handle errors well but your server doesn't handle a load well and at least my code will never get /.'ed.
Check your return values!! As simple as it sounds, so many people just don't do this. Everyone just assumes that everything will go ok. Check the return, then print out an error to stderr. To be more helpful use this define just before you print your error message to help find where the error was and debug it. :", __FILE__, __LINE__)
#define ERR_LOCATION fprintf(stderr, "ERROR in File: %c Line: %d
Then use it like so:
ERR_LOCATION;
fprintf(stderr, "foo returned %d.\n", ret);
I believe that's the correct code.
Outdoor digital photography, mostly in New Engl
open source programmers suck at error handling? damn... i could have told you that. i suck at it. i hate it. error handling is a pain... especially when a C function can return five or six different errors. it's so much easier to just assume that there's four of those that will never occur.
that isn't to say we shouldn't do better... but open source projects don't tend to get error handling really done until the project has picked up a lot of users and developers. the kernel kicks ass at error handling... so does X11.
And which makes more sense to your average Joe using the application?
If you want to be friendly to your users, changing a couple of trivial words actually isn't a waste of time.
"Performed an illegal operation" makes sense to most people - it did something not allowed
"Seg fault. Core dump" means nothing unless you know how to "fault a segmentation" and what a core file is.
Of course if you can actually attempt to explain what went wrong, then that's better again... Otherwise just make it meaningful to the lowest common demoninator you would like to use the app/os.
I don't think that a straight comparison of open source to commercial software, in the context of error handling, has any merit.
I'll try to illustrate with an example. I'm running IE 5.00.2920.00 on Windows 2000. I get a huge number of "Cannot find server or DNS error" pages from IE. You know, those are the stock HTML files that IE displays that say "The page cannot be displayed", and it has a whole boatload of gibberish on it about clicking the Refresh button, contacting your network administrator, checking URL spelling, etc etc etc.
Unless the host machine is truly unreachable, I can click "Refresh" and get the appropriate page almost instantly about 80% of the time. Does that make you smell a fish? It makes me smell a fish.
The fish that I smell is commercial software handling errors in such a way as to blame anything other than itself when it encourters an error. I'm sure this works on most Windows users, because they've never used anything else, and their desktops crash all the time. Why shouldn't web sites just arbitrarily refuse to give up a page now and then? But if I'm debugging a web server that I'm telnetted to from my SPARCStation, and IE on Win2K claims that the web server can't be found 12% of the time, yet finds it instantly on refresh, I begin to see a pattern.
If you write commercial software, the pattern is to including fairly complete error handling, but make the error handling blame something else. IE didn't choke, DNS or the remote server did, or you typed the URL wrong. Anything but admit that IE had the problem.
Open source programmers don't experience pressure from marketeers and PR people and "product managers" to appear blameless. Open source programs tell it like it is, up to the limits of the programmer's articulation. That's why it's useless trying to compare the two: commercial software handles errors in order to shift the blame. Open source software handles errors in order to provide debugging information.
Poor error handling is due to poorly trained programmers (of which there are too many), it is not a function of the language.
Wait for it...wait for it...ahhhhh!
Maybe one out of 10 does it well.
Hey - I don't need any mod+ on this, but have to agree with you. Tomcat isn't a triumph, which is why I added the caveat that I was only referring to it's error-log implementation and configuration.
Apache is definitely a triumph.
This is about detected bugs which haven't been fixed yet.
Basically, his complaints boil down to, "bugs exist, causing error messages, why aren't all the ones that cause error messages fixed yet?"
Then he goes off on a confused tangent, apparently suggesting that "error handling" be added to work around any bugs. After all, if it can log the errors caused by bugs, it can respond to them in any way, up to and including fixing the problem (i.e. doing what the code should have done, except for the bug)! For example, if a system file is missing (meaning either a bug in the install, a bug in the program requesting something that isn't really a required system file, or an externally damaged system that can't be expected to work at all), just pop up a dialog to let the user search for it! Because of course the user should attempt to patch things up with his intimate knowledge of system internals instead of just seeing that there's a bug to report.
Hooooo boy....
I didn't see a single example of a genuine external error that wasn't handled properly, just bugs which should be fixed.
Uh - I don't know where you're getting this.
"Completely theoretical" ?????
Please - raise your hands if you've ever actually developed anything beyond asp for IIS?
It crashes left and right, with no memory protection for in process DLLs or custom proxy-plug-ins.
I don't care about the mod for this, but IIS is a piece of crap, with poor logging and it's easy to crash.
He chose some pretty bad examples of bad error handling - they all gave the module and direct cause of the error, and provided ample clues for the programmer in each case to go find out what went wrong. If we're looking for anything that open source programmers do that stinks, it's making GUI apps that pretend nothing's wrong.
Way to go, I say. Would rather have hugely detailed warnings any day.
Dave
I write a blog now, you should be afraid.
1. Most open source developers are lousy at writing good error handling.
2. Most closed source developers write error handling routines that pass the blame to someone else's code or are not helpful.
3. Open source means you can fix the code. So stop complaining and do something useful.
--- Will in Seattle - What are you doing to fight the War?
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
What about the windows version of Tribes 2? (loki did the linux port ,and it's rock solid)
"Unhandled Exception at " Is the buzzword of the day.
Perhaps on average open-source software is buggier (due to programmers with larger 'maverick' streaks), but there is still some shocking commercial stuff out there.
A classic example of horrible error handling:
} else if (!(status & LP_PERRORP)) {
if (last != LP_PERRORP) {
last = LP_PERRORP;
printk(KERN_INFO "lp%d on fire\n", minor);
}
error = -EIO;
Tell me that's not irony right there.
The answer is yes - commercial software handles lots of things better - they're paid to put out a good product. Sometimes deadlines get in the way, yes, but hey is that Mozilla finished yet? That's what I thought
Proxy Error /site-stories/2001/1025.errorhandling.html.
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET
Reason: Could not connect to remote machine: Connection refused
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
how is a programmer expected to deal with the CD being scratched? Does your car still work if the transmission is damaged or half the engine has been riddled with bullet holes?
Again, a very unexpected and unnatural scenario. How well do cars function when they run out of fuel?
But how well would your refrigerator react if you treated it shoddily such as by leaving it outdoors intermuitently or diconnecting and reconnecting the power several times a day?
Now, I'm not trying to excuse sloppy software development but the fact of the matter is that software is constantly expected to work perfectly under situations completely outside its specifications yet we don't expect this from other items or appliances that we use.
First let me say that I am a Linux user and an open source advovate.
Now let me compare this to a judge I once met, who said that men have more tickets in general, but women always follow too close.
This is interesting, but if we further evaluate, one could conclude that women are just as bad (equally so), but perhaps people were lighter on them along the way. A police officer might have let her off, and so forth (this isn't to sound mysogynist of course, but I know women who get let off all of the time).
Instead, following too close is an easy prelude to... an accident. After all, when your bumpers are crushed together, you're too close.
Now think of error handling. "Open Souce Software handles errors poorly," is another way of saying that it too crashes a lot. Perhaps other people get caught for other things, but we only rag on open source when it crashes.
This isn't to say ALL open source software though.... but lets be perfectly honest. Programming is a difficult profession that a lot of people think they can just pick up. How many people would volunteer to do surgery without med school because they read a book on the subject? How many people get offended when you flash some important programming credentials in front of them that they don't have?
The trick is sifting the wheat from the chaff. Sure, a 14 year old with a little ambition can whip up a pretty impressive looking windowed program in X... but he doesn't have the sophistication of a well educated programmer... generally. There are plenty of good programmers and bad programmers in open source. The key is to know whats good and whats bad. If you can't figure that out, then buy a distro made by people who do.
I always find that if I am testing for tons of possible errors deep in my code that what really needs to happen is some minor logic changes at a higher level that make the error conditions impossible to exist.
Heh, the link to the site gives me a Proxy Error. ;-)
sigs are a waste of space
Exceptions make sure that if an error occurs, and you aren't aware of it, your program dies, and doesn't go on its merry way, causing a security hole/unstable software.
You mean like that Ariane rocket that blew up when its double-redundant computer system was halted because of an utterly irrelevant uncaught exception? Yeah, that's definitely a superior error-handling philosophy.
Aside from the conceptual problems of what are essentially COMEFROM statements with scope management, there's no reason to assume that halting the program is better than just allowing it to run.
What percentage of Open Source programmers are commercial programmers in their day jobs?
Open source programmers may suck at handling errors, but commercial programmers suck much more.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
No, I don't. "Alpha" versions of open source programs do obviously. But the commercial software I'm used to (Windows) can lock up the system. Don't know if its the fault of the apps or waht, but...
Oh the irony. http://www.linuxworld.com/site-stories/2001/1025.e rrorhandling.html yields:
/site-stories/2001/1025.errorhandling.html.
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET
Reason: Could not connect to remote machine: Connection refused
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
I think there is a definite need for a high level language with strong error handling. Stuff like automatic checking for buffer overflows on all input and output, automatic checking of data types on every instance where a variable is used - and built in units checking, i.e., a formula needing inputs of feet will automatically convert from meters and not allow you to input something of units of pounds or seconds (only units of length).
I'm sure there's lots more error checking that could be built into a language that would be a bitch to get through the compiler or interpreter, but would make a program more trusted in the end.
We could call it "anal"...
There are 10 types of people in this world, those who can count in binary and those who can't.
...and in that moment, he became enlightened.
When all you have is a hammer, everything looks like a skull.
Comment removed based on user account deletion
A recent experience with JBoss had me cursing open source software for this very reason. I'd accidentally declared a JBoss-persisted field 'private' instead of 'public' (as we later found), but JBoss' not-so-helpful response was to throw a NullPointerException. Ironically, I discovered by reading the source that it was actually bombing while trying to construct a more helpful error message!
It was helpful, however, to compare this with an earlier experience with WebSphere 3.0. Whenever you did any number of incorrect actions in the management GUI (such as giving two servlets the same URL), it brought up a nice little dialog with a similarly inpenetrable RemoteException stack trace. Useful!
The only pratical difference between the two was that JBoss' cryptic message could be deciphered by reading its source code.
When a luser complains about error messages, I punch him in the face. I'm getting less and less bug reports that way.
Here is a pwd that will never dump core, barring faulty memory:
#include <stdio.h>
#include <unistd.h>
#include <limits.h>
int main() {
char buf[PATH_MAX+1];
if( !getwd(buf, sizeof(buf)) ) {
perror( "getwd" );
return 1;
}
puts( buf );
return 0;
}
I agree with you that software in general is a lot more complex, and used in a lot more unexpected ways, than something like a car.
OTOH, there is such a thing called graceful degradation -- that is, if you push the limits of the software, it shouldn't just suddenly barf and die on you, but degrade gracefully. Too much code I've seen (both open and non-open source) assumes too much -- and dies badly when the assumptions fail.
It is possible and not overly difficult to design software such that it degrades gracefully. Sadly to say, sloppy programming (programmers), deadline pressure, or disinterest in handling error conditions, dominate the world of software. Not many would put in the extra work to make a program degrade gracefully, because it doesn't have very visible effect -- until things start to fail. And too many programmers have this "test only the cases that work" syndrome.
Poll Mastah
I would contend that Commercial Pressures (tm) cause a *lot* of closed source programs to be released without this kind of error checking. I'm not saying it's OK to write code without error checking, but that the reality of it is that a lot of commercial software is released without error checking.
Open Source software is quite often developed by the programmer with a view toward 'correctness' rather than a view toward a July 16 release date (or whatever). It is this software that I would expect to have a lot of 'good' error checking. A lot of other Open Source software, however, is developed by a programmer for personal use, then released to the community because 'others might find it useful'. It is this software that is likely to have less stringent error checking (not always, but less likely).
So, sure, some OSS will have lax error checking, but there is an awful lot of OSS with exceptional (pun intended) error handling.
I think the generalization is gross at best, and inaccurate and wrong at worst.
he was quoting from an article about IIS security flaws...it was a comment from a M$ spokesman claiming that the supposed buffer overflows were completely theoretical and could NEVER happen (I believe that's what he said, anyway)
--Jubedgy
Si hoc legere scis nimium eruditionis hebes
Not Found /site-stories/2001/ was not found on this server.
The requested URL
Additionally, a 404 Not Found
error was encountered while trying to use an ErrorDocument to handle the request.
You get the above when you try to access that url on the server hosting the above document. Ironic? I think so. Maybe linux journal should handle it's own webserver's errorhandling before blasting others?
- Better to speak your mind than to remain silent, or someone may speak for you.
you think checking return codes is the solution? Well, it is but at a cost.
Exercise for /. readers: add errorchecks to the following C function. 'return' and exception handling pseudocode allowed:
/* Here we do something with p1, p2, p3 */
int allocate_3(void){
int *p1, *p2, *p3 ;
p1 = malloc(SOME_NUMBER*sizeof(int)) ;
p2 = malloc(SOME_NUMBER*sizeof(int)) ;
p3 = malloc(SOME_NUMBER*sizeof(int)) ;
free ( p1 ) ;
free ( p2 ) ;
free ( p3 ) ;
return 0 ;
}
Let the game begin...
I would like to see this: All /. readers add a comment to this thread. In this put the OS projects that you have worked on or are currently working on.
Me: none......so I don't comment on things like this.
I must have been transported into a parallel universe, first a story thats negative towards Open Source on /. and then I cannot find any of the usual "Imagine a Beowolf cluster of errors", or "Is a Beowolf cluster of errors a cluster fsck?" and where oh where is "All your errors are belong to us", if anyone has directions back to my normal reality please help me.
Any sufficiently advanced man is indistinguishable from God
Open Source sucks at error handling? Look at the standards in the PC industry.
They've been declining in general for the past 10 years, and before that they sucked as well. I think the standard is really set by the hardware itself.
Typically drive errors can have symptoms of software running more slowly as the drive retries - or applications will simply appear to hang, or if it's an error reading code into memory, well, anything goes.
Network errors can go completely unknown until you haul out the crusty old hacker with a sniffer - oh gee, did you know that your card is dumping half it's packets?
Oh - especially network problems - where the software at the user level 90% time just sits there and goes "Duh!" for simple things like pulling the cable out.
Error checking and handling, in general, SUCKS and it's the main reason why computers suck - why the software industry spends billions of dollars chasing problems during the development phase that they never really get to pin down, so the problem ends up going into shipping products.
I blame the lax standards on the platform, and the dumbing down of programming in general (the over-reliance on high-level languages that remove the programmer progressively further and further from the hardware their programs run on).
If PC's had better standards for this sort of thing at the hardware level - and if the vendors adhered to those standards, then the software people could write software that handles errors better, and it would bubble up to the user level as more reliability, and much simpler troubleshooting, probably tens of billions of dollars saved in productivity alone, and probably the PC industry would be 10 times the size it is today, because people would actually trust them for important tasks, rather than the next nifty home killer-app like pirating music. (not meant to be a troll against MP3 trading - meant to be a troll against the apparent purpose and direction of the PC industry in general).
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
If the language you are using doesn't support exceptions (C, Perl, etc), you are going to have problems. Exceptions make sure that if an error occurs, and you aren't aware of it, your program dies, and doesn't go on its merry way, causing a security hole/unstable software.
Unless it's an uninitialized-memory error or a buffer overrun that overwrites some other program variables, in which case a C++ program will still keep going on its merry way without throwing an exception, causing difficult-to-duplicate and hard-to-trace bugs.
If it's possible to check for the error at all, then anything that you can implement with exceptions you can implement without exceptions (though I agree that exceptions are a _neater_ way of doing it).
If your program can't check for the error (as is common for memory errors without extensive and slow wrapping on memory accesses), then exceptions won't be triggered and you're still screwed.
[Aside: You can propagate error codes up between levels either by making error codes bit vectors and masking subcall errors on to the parent call's failure code, or by implementing your own error stack (if you anticipate using deep recursion). Messy, so exceptions are still _preferable_, but it can still be _done_ without exceptions. Almost as cleanly, if you wrap error-handling helper functions nicely.]
The biggest problem is that most errors can't really be handled. If your pointer comes back NULL, it is likely a problem outside of your control. For example, if it is because there is no memory, you can simply let it SIGSEGV, or try to put up a message - but if the library needs to do a malloc, it would likely fail within the library so you would get some other bad result.
Or for example, a file open that fails. Maybe you don't have permission, or maybe it doesn't exist. Or maybe it is locked by someone else. Or maybe the filesystem is hosed. Most of these are unlikely events. You get instant bloatware if you now have the 1000 detailed messages explaining exactly why the file couldn't be opened. But does this improve the user experience? Maybe the most common are good (e.g. displaying the path might make a misspelled file or wrong path obvious).
Others have pointed out the deficiencies of other OS error handling (BSOD, unhandled exception boxes, etc.), but even WHEN IT IS HANDLED, it often means the program must be aborted - it just sits there waiting for you to click OK. I find this even more irritating since I have to spend extra time fidgeting with a dialog box instead of restarting the app.
News flash: Technology pundit seemingly insults open source, Slashdot up in arms. None of them actually read the article. Story at 11.
The article does not say "open source doesn't handle errors as well as closed source". What the article does say is "like most commercial software developers, many open source programmers are just plain lazy about proper error handling. But we're supposed to be better than that...".
I don't see a problem with this statement. The fact is, most open-source software sucks donkey balls. Petreley is merely saying it's time to put your money where your mouth is -- if you want open source to be considered better than closed source software, it better stop being so danged flaky.
ZFS: because love is never having to say fsck
The issue isn't about OSS. It's about solid programming practices that encourages good document, thoughtful design and good exception handling.
Open source programmers are basically the same people as commercial programmers, maybe by night or maybe as different jobs come and go. The difference is that most open source projects arise from a person's need, and it is natural to ease up on the effort once that need is filled, i.e. once the program is good enough for your personal use.
Do you think commercial software handles errors better?
Of course it does. Instead of a generic bug error popup I get a nice smooth bsod, so I know exactly when I need to restart my computer and loose all my work.
a system that has been revised throughout development to have rock-solid error handling/reporting/recovery.
What is an application supposed to do when the user presses "Save" but the OS gives error "Disk full" and the file is larger than 1.44 MB? What about fopen() failing with "Not enough memory to allocate a FILE structure"? How is code supposed to recover from that kind of error without losing data (i.e. the document the user is editing)?
Will I retire or break 10K?
Well, we all know how bug-free Internet Expl...<This program has caused an illegal operation in module kernel.dll and will now be terminated>
One thing that really bugs me about most programming languages is that they only allow 1 return value by their most natural idiom. So you get these stupid hacks where some settings of the returned value mean errors and some are useful results, of you have to define a new named data structure just for the return value of this one function, or you end up having to mix output variables with the inputs for a function.
This is one thing I like about Forth-style languages, where it's just as natural for a function to return multiple results as to receive multiple arguments, letting you do either:
A B / on_error{ log_error cleanup exit }else{ use_result } return
or
A B / on_error{ store_exception drop_result push_unhandled_exception_errcode }else{ use_result } return
or
A B / drop_error use_result return
Unlike with exceptions, the possibility of an error isn't hidden away somewhere; if you ignore it, or hand it down to reach exception handling code, you have to do so right there and then, explicitly at every step. Actually, that's a general plus: with a stack language, you have to explicitly dispose of everything, which makes it harder to ignore return values, and impossible to write programs without knowing whether a function returns anything ("What do you mean it can return an error code? I though it was void!").
Sloppy programming is sloppy programming, open source or not. Most programmers are sloppy and don't do error handling carefully. I'm sure the (rather high) percentage of open source programmers that do a lousy job with error handling is comparable with the percentage of non-open source programmers that do the same. Most things suck in all walks of life.
max
Linuxworld is having issues, so I can't read the atricle, but I remember Petreley from when I used to get Inforworld Magazine.
He's the stereotypical technology pundit. He learns just enough about technology to have an uninformed opinion about it.
The worst thing is that we on the internet have truckloads of people like him. Every mailing list, newsgroup, web log, IRC channel, or any other group in which people or trying to get things done will have a crew of wankers spouting their opinions with no attempt to actually contribute anything useful.
What really burns me about pundits is that they're getting paid to do what a couple million monkeys on the internet do for free.
Take Petreley. One time, he wrote an article about how maverick programmers don't write good code. I guess I can believe that. Then he went on to say that all brilliant programmers are mavericks, and Microsoft etc all hire them so they'll write bad code and people will have to buy bug fixes. Um, right. He then finished off by claiming that he used to be an absolutely outstanding programmer and that he had to quit because he was so amazingly good that writing decent code wasn't fun for him.
He has, to the best of my knowledge, never actually contributed anything at all even remotely useful to Free Software, or computing in general. He's even worse than Fred Langa, the guy who helped invent ethernet in 1976, then spent the rest of his career punditing, developing more and more bizarre opinions as his practical knowledge became antiquated.
So here's a message to Petreley: Do something useful, anything. If all you have to contribute is your opinion, then go home. Free Software writers are mostly volunteers, we don't have to put up with your wanking. If you have a problem with a program, file a fucking bug report. Actually, if you're such an amazing programmer, SHOW US SOME CODE! I don't care how much Infoworld pays you, to us, your opinions are worthless. So do something useful or, I'll have to dig out my cluestick and use it bash you into a profession that benifits humanity in some conceivable way.
Jordan Bettis
``Wherever you go, there's another stupid sigfile quote.''The problem is as i see it that the Open Source :) .. but when it comes to the nasty problems of how and when to handle errors or exception conditions, it is no longer fun, but tedious work and thus is left on the back burner..
Programmers are more interested in getting something to work... this is what most of us want
to see
who then is willing to jump in and add error handling code to a module when the fun stuff (it is already up and running) has already been coded?
That's right, open source software sucks at nearly everything it does![1]
Open Source as it stands today is great at bashing together a really "neat" program which gets the job done in a specific manner. Soon enough, lots of cool little features are added in, and before long you have a 'perpetual-beta application.'
Programming, however, requires some discipline which doesn't often get put towards OSS. Programs require good error handling (and error trapping, for that matter), usability (That means intuitive interfaces), and documentation. Oh yes, and freedom from bugs. However, these things are BORING to produce, compared to the original plan of bashing out a neat routine.
Ironically, the only way to achieve such things in a distributed and open development model, is to have a central administrative point. Without it, large projects are just impossible. Funny, eh?
[1]of course, so does commercial software, but in different ways)
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
...of course we suck at it. Open source doesn't have bugs, remember?
No comment.
Ryan Wright is a moron. Intelligent people don't make blanket statements about others without at least a bit of information. Next thing you know, he'll be telling you "The world is coming to an end." just because he saw it on a sign. How the hell does he know it is ending, perhaps there was more on the paper that said the world was coming to an end, and a new one is coming, even better.
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..
/*
/* Here we do something with p1, p2, p3 */
The trick in writing C code that handles errors correctly is to know your
scope. Whenever you have a constructor (such as malloc() or fopen()), try
to put your destructor (such as free() or fclose()) in the same scope, unless
of course you are writing a constructor or destructor for some datatype.
*/
/*
Sorry for the readability issues, but Slashdot does NOT like code. When
I used my standard method header, it told me I violated "junk character".
When I removed the asterisks from the method header, it told me I still
violated "postercomment compression". Here, I use the preprocessor to
compress the source before the lameness filter sees it.
*/
#define LMNS1 malloc(SOME_NUMBER*sizeof(int))
#define LMNS2 else rval = ENOMEM
/* allocate_3()
Description of method.
Returns 0 for success or an errno code for failure.
*/
int allocate_3(void)
{
int *p1;
int rval = 0;
p1 = LMNS1;
if(p1)
{
int *p2 = LMNS1;
if(p2)
{
int *p3 = LMNS1;
if(p3)
{
rval = 0;
free(p3);
}
LMNS2;
free(p2) ;
}
LMNS2;
free(p1) ;
}
LMNS2;
return rval;
}
/*
I will REMOVE your "All Your Radical Touching Base Are Already Occurred to The Lesbian Monkey Puppy" Philosophy on me if you don't eat my soy google balls, hatt-baby. Real or Malarky?
*/
Will I retire or break 10K?
I'll be blunt, too. I got your fix RIGHT HERE! I have whipped up some open source magic that uses a powerful error-finding heuristic in combination with a correction algorithm. It should fix all of these problems you have described.
----CUT HERE----
#!/bin/bash
if [ "$#" -lt "1" ]; then
echo "Usage:" $0 "<program> {<args>}
exit 1
fi
$* 2>/dev/null
echo "All errors corrected!"
----CUT HERE----
You are not expected to understand how this works. Send me beer, we open source guys like that.
This sig is false.
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.
C's strerror() uses another approach: a short 6-character name for each error ("no such file or directory" is ENOENT, etc.) that stays constant across localizations.
The situation is even worse for people who used localised versions of the software, as you don't have the English translation
Whether you get "Non ci è tale archivio o indice (ENOENT)" or "Es gibt keine solche Datei oder Verzeichnis (ENOENT)", you can still search on the ENOENT. (Translations by Babel Fish.)
Now if only the popular apps did this...
Will I retire or break 10K?
A very smart guy from SGI once told me "A core
:-)
dump is the best possible error message because
it contains ALL the information you need to
diagnose why the program had to stop running."
Mmmm'K
Want to improve as a programming in terms of how you handle errors? Be assigned to 7/24/365 support of your product. When it tips over, deal with the irate user. When its most minor function doesn't work, get paged out of bed at 3 am. Have it do something important with lives at stake and then just _try_ to walk away from a half-fixed problem or say SEP.
Once you've been on this hook, you look direly askance at poorly documented code (even code you wrote three years ago), code that doesn't do required error checking, needlessly convoluted code, and code which isn't easy to read at 3 am when the live system takes a hemorrage repeatedly and someone might not get a 911 call through...
Once you've had to put yourself in the pressure cooker some clients have to deal with, you develop either a) sympathy for their situation or b) a great desire to never ever ever hear from them again. That's a good motivation to quit or to do the damn thing right in the first place.
Too many coders are allowed to write crap, churn it out as a release, and then not worry about support, either doing none or passing it off to some other poor bugger. If core developers got stuck supporting what they wrote and their own laziness or poor planning came back to bite them on the ass, they'd learn rather rapidly to improve their code quality and handle the errors in a robust manner the first time!
Been there, learnt the lessons, DESIGNED the T-shirt....
Tomb.
-- Mal: "Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious."
Ever use a commercial unix? I use HPUX at work and True64/Solaris at school. Of those, linux programs are the most understandable when things go awry.
Linux is a recreation of a system that has historically been 'terse'. Can we expect it to be very different?
Apache?! I'll grant it generally works, but it's selling point is it's price tag. The quality is fine but it has nothing special to offer, it has merely okay performance. Before Apache is useful you have to add Tomcat and that is a pain in the arse.
Anything beyond that -- for the programmer -- is simply fluff and busywork to impress someone.
Get off my lawn.
In sequence:
Basically, almost all the messages he mentions are indicative of broken code. It may work, but that doesn't mean it's correct by a long way, and that these problems exist is just poor workmanship on the part of the coder responsible (assuming these are all meant to be stable releases - if not, someone please shoot the writer for missing the point of alpha/beta tests.
The remaining messages indicate minor problem - none of this has anything to do with error handling, and everything to do with testing your code properly before releasing it!
It should not matter what one iota if closed source handles errors better. Its only a question of whether open source handles them as perfectly as possible.
There is one factor of open source that seems to be over looked in the evangelism. Yes open source is subject to peer review, which is one of its primary strength. However, if no one reviews the code, the advantage is not gained. Even if the code is reviewed, if its not done by a competent programmer, false confidence in code quality could result.
Poor code reviewed by poor programmers is a dangerous combination, open or closed.
DOS is dead, and no one cares...
If there's a Bourne Shell, I'll see you there
...Amazingly, with all these errors and warnings, most of that software continues to run. Compare that with the way typical windows applications work (Crash on the first error and take out something important on your way down), that sounds like excellent error handling to me....
Just my $0.02
"Your superior intellect is no match for our puny weapons!"
I noticed that a lot of the errors he was talking about were missing files, blah blah blah. This I have had problems with in X using various managers. Here are some answers... a lot of the time missing files are do to lack of checking the required packages. Also it can have to do with the way different Window Managers handle different things. I would like to see the results of these little tests done on machines that were running every available WM. I bet most of the problems with the GUI based programs that he is reporting are due to the fact that they were written on a machine running a different WM. Just my thoughts.... if you don't like it don't read it :P.
Later
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
Developers: Microsoft Programmers Stink Even More At Error Handling
they work full time, they get a regular salary, and their best uptimes still cant beat linux's best uptimes. something's just not right.
Are you pondering what I'm pondering?
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?
Not just at error handling, open source programmers just flail in general. If they were any good they'd be able to find someone to pay them.
This may seem obvious, but a lot of developers (myself included all too often) get caught up in excitement about a new project and start coding prematurely. The project should be designed (to a level that corresponds to the scope of the project, of course) before any programming starts, including prototypes. This includes designing for error conditions.
Finite State Machines are an excellent way to model the way an application handles error situations (in addition to others). This technique forces a developer to think about these circumstances beforehand and to think of ways to maintain well-defined behaviour.
Of course you won't be able to find every bug and error that can occur, but thorough testing helps. Bug fixes should always be checked against the design so as not to introduce more bugs.
Sorry if this sounds really preachy, but it does help.
Requirements are specified in design documentation.
/. is ever likely to run.
Each instance of Error checking or Recovery must be specified, just as the format of each element of output or the formula for each calculation must be specified.
Without that specification, who cares if you think the code is wrong? You can't prove it's wrong because you don't have the spec and didn't pay for its development. You bought (or five-finger GPL'ed) a license to operate the software. On an as-is basis, for every piece of software anyone posting to
You want it improved? Write the Engineering Change Request specifying the improvement, and send it along with the money necessary to get it done.
Design and validation of "bug-free" code is the most expensive software process there is. Just the paperwork on the validation process will double or triple the cost of the software. The problem is provably impossible to solve, and the best efforts on nontrivial code (and sometimes on what appears to be trivial code) end up with unresolved errors that are signed-off as calculated risks the costs of which will be borne by insurance, government, lucky avoidance of catastrophe, and the bottom line.
--Blair
"And it pays my bills, in spades."
How dare he even think of critizing open source software or programmers?
ardax makes the point above, but is only scored 1, so...
:-) and I expect it to continue running indefinately. About every 5 years I put a drop of oil on the fan shaft behind the freezer to keep it from squealing. Software has a ways to go.
First, about your analogies...
If I wear out the door key to my car, the car should not burst into flames when I try to open the door.
If my car runs out of fuel, I expect that after rectifying that little problem (and bleeding the injectors) it will be just like new. I do not expect that it will ruin my tires.
And yes, I have kept my refrigerator outdoors. I kept it on the front porch for two months while the house was being renovated 10 years ago. It worked just fine. It is 30 years old now (Thats 15 PC generations to you young whippersnappers. Moores law says the new fridges should be 1,000,000 times colder now.
About the cubase incident...
Yes, the CD is scratched. I expect that I won't be able to re-authorize my copy of the software, but don't ruin ALL the data on my hard drive! (Its actually worse. It was my wife's laptop. You do NOT want to have to tell my wife that you just wiped out her laptop.)
About Word...
Destroying the on disk copy of a document before successfully writing out the new copy is just plain stupid. Particularly on a Mac where there is a special file system function to swap two files. You write the new copy under a fake name, swap it atomically (even over file severs) with the original file, then delete the fake named file (which now contains the old data). No one gets hurt in error conditions, no one can ever have bad luck timing and read a partially written file off the file sever. Life is good.
The third case (The PSC) you don't mention, but it isn't really a case of graceful degradation. Its just an irritating bug. Honestly I'd dump the device because of the irritation, but it actually feeds card stock out of its paper tray! A rare quality in a printer.
I suppose the more explicit point I should have made is that bad things are going to happen to software and it requires effort from the programmer to deal with it. Sometimes just a tiny bit of effort. Cubase performed so badly with a bad CD that I suspect they never tested it. They write about it in their documentation, but they probably didn't test it. The Word example is just careless programming which could have been trivially avoided if the programmers understood the platform's file system calls.
How about the cost? I estimate that it probably doubles the engineering effort to handle the exception cases to a degree that would cover the incidents I note above. In the calculus of software development the benefits do not out way that cost.
of those patterns that pop up everywhere that look alike.
like bad enlgish.
and the quality of these posts and moderations.
Most life forms on this planet are "buggy"
ain't it fun?
rehab, captain ahab, you're chasing the wrong fish!
cout << __FILE__ << ":" << __LINE__ << " foo isn't in bar\n";
That way not only do you get an error message, you get a tip to the source file and line number where the error occured.
Certainly it's not helpful to the end user, but it does make it easier for the obsessive-compulsive programmers to find and fix the error on their own.
MAC | A polar bear is a cartesian bear after a coordinate transform.
It is just getting so old. Why must so many commentators act like snot-nosed punks?
The preferred word is SUCK. 'STINK' is just a stupid pussy word.
Error handling sucks because it is a pain to program and test. To do it proper in most API's requires heaps of boilerplate code that will increase executable size and also needs to be tested. All those return values that need to be checked. If I know smothing went wrong in the layer bolow me, I often have no proper error message to present to the user. I'm not talking about responding to wrong user input here, if there is an error in a config file any program should and could give a proper error. It is when, as a programmer, you are not in charge of the interface when things get hard.
Error handling is one of those areas where many programmers have to reinvent the wheel, but hey, we are open source, we can share and can do better! I would be great to have a standard error handling framework that converts from return -1 and use GetLastError to raise an exception. Set standards for error reporting to include, description, probable cause, recommended action, severity etc.
http://slashdot.org/articles/99/01/10/173223.shtml
--Mike
"Not an actor, but he plays one on TV."
It's a backlash against the hype from not so long ago that said that closed-source software was not only technically inferior but also unethical to produce. Frankly it was pretty insulting.
I can tell you one thing I know for sure. The open source community did a very good job at writting the linux kernel.
BTW I ran into a strange Windows 2000 kernel crash lately. According to a debugger, it crashed in a function named:
CcWaitForLazyWritterActivity
I don't know what it was doing in there. I am not sure if I event want to know. I can tell you that I would have chosen another name for tin function.
I don't know how you did it, but my sincere congratulations :
The fact is, most open-source software sucks donkey balls.
Moderation Totals: Insightful=1, Informative=1, Total=2.
Last post!
So Windows will dump all the RAM to a file. So now what are you going to do with it? It's not like you can actually read it easily. In all my time working on NT I don't think I have ever resolved a crash from that. Of course I haven't developed any drivers or anything so maybe it would be useful then.
I'm also working on a temporal-spatial feature-oriented library and application suite to support USGS research. Once it's mature it'll also be released as OSS.
MAC | A polar bear is a cartesian bear after a coordinate transform.
Yes, I too am tired of the constant error messages. I bet you'd get far fewer of them if you programmed in Ada. It's specifically designed for safety-critical software, i.e., error-free software.
C and C++ are far more error prone than Ada. One study found that Ada can cut development time in half compared to C/C++ because the programmer need not spend prodigious amounts of time tracking down segmentation faults and other such crap.
I watch Brit Hume on Fox News
Or else he wouldn't think that only open source software has lousy error messages...
The user should not see errors unless they want to. I agree with sending errors to STDOUT. If the user wants to see the errors then they can either start the app in an XTERM so they can see the errors or switch virt terms over to VT1 and see the STDOUT output.
Also, I use error reporting to a logfile rather than alarming the user. Most applications should be able to survive the average error. Those applications should prompt the user for proper input - even to the point of placing the cursor in the proper field. Each field should be intelligent and be able to validate it's own input data.
Those error logs I spoke of should be used by the programmer to debug his/her application - don't alarm the user ok?
Codifex Maximus ~ In search of... a shorter sig.
Something similar but worse once happened to me. I was editing something with Word while browsing the web; not doing anything out of the ordinary. I saved the file and logged off for the day. When I tried to open it again, Word refused, claiming the file format was incorrect.
I looked into the .doc with a hex editor and found that some HTML source had somehow found its way into the .doc! I was using win95, so I guess this can be chalked up to buggy filesystem code. The weirdest and most frustrating bug I've ever seen. I didn't manage to recover any of my work.
doh! heh make that STDERR heh :)) Must remember that Preview button.
Codifex Maximus ~ In search of... a shorter sig.
I don't think people are bashing the free stuff, but more along the lines of giving it the same type of scrutiny that everything else is given. Honestly if people can't take any criticism at all, you better crawl into a hole, because the *real* world is a scary place.
There is a famous mantra, all programs suck, some more than others (I'm replacing the original word OS's with programs, cause it still fits perfectly). That goes for closed, open, free, expensive everything; all programs suck, and being able to openly talk about deficiencies in them is the only way to make them suck less. It strikes me as rather two faced complaining about "people bashing free software", when just before that *you* bashed other software, for the same legitimate reasons others supposedly "bashed" free software. Again all programs suck, being critical of them makes them suck less.
Tell me about it. We have a service offering where each of our clients has a different virtual root under IIS 5/W2k. Right now we are at about 80 customers and at least twice a day we have to reset one virtual root or another because the IIS process crapped out and stopped responding. This is with memory protection set to high (seperate process) too.
Well known bug. When writing blocks out to disk, it doesn't remove the previous contents. You were probably seeing part of a cache file.
In most cases (particulary GUI programs) there may be little things that the system can't do. Can't find an icon, a pixel map or a help file. How annoying would software be if it asked you to try and find *every* little thing that it could not find, irrespective of how insignificant to the running of the program.
I think it is one of the great things about OSS that on the whole the developers are prepared to print a lot more error/debugging information than most closed source software as it gives you half a chance at working out what went wrong. Much better than hiding them where no one can see (as hapens with a lot of software).
Don't get me wrong we should all be striving towards better quality software but the number of error message you print is a pretty bad metric for software quality.
Kelv!
Read the article. That's exactly what he said. Here's the title and the subtitle:
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
I agree with Nick. Programmer Error handling sucks, but not just in Linux and Open Source. An example is at work, we had a programmer write a batch file to concatenate(sp?) two to five files together into one big file. Only thing is it depended on a network drive mapping (on a volume up on a Novell server...yech) and files to be there. If the batch file failed, there was no way to know it failed because of a network drive mapping error because bloody DOS has no frickin return codes. I WISH they'd let me and the systems programmer set these dang things up on a linux box so we could write a BASH or TCSH script with proper error checking so we could provide a return code back to the mainframe that triggers the script. That way the mainframe could holler at the operator that there's a problem. Right now, if the batch file fails it just drops thru. If it wasn't going to be replaced soon, I would rewrite the damn things, but since a new system will be entering implementation soon, we will be freezing all development except for fixing errors and fulfilling state/federal mandates. Hopefully the package we are going to (anyone ever heard of the education only package called Colleage by Datatel?.....it runs the business side as well as the scheduling, record keeping and all of the stuff a college computer system is doing....). Anyway, at least the picked the right OS and, in my opinion, the right DB for it (AIX for OS, and Oracle for DB......the other choice was....shudder....NT/2000 for OS and I believe SQL server, but it may have been something like DB/2 or something weird).
Gorkman
It seems that what he really annoyed by are all the error messages scrolling by on his console. IMHO, error messages are great. For example, I just reinstalled Windoze 2000 (hey, I need my games) for the 3rd time this month, because InstallShield stopped working, and I couldn't find out why. If I could read some log file somewhere, or look at a console, and see a message "InstallShield error: file xyz.abc is missing; assertion failure in Foo.c line 12345", I could at least try and fix the error. If source code was available, you can bet I'd go to line 12345 and fix it there. Anything is better than spending another 3 hours restoring my settings from scratch.
In addition, while that guy was looking at all the nasty error messages, his software was working (most of the time). Perhaps it was working only partially, but it was working nonetheless. This demonstrates that errors are actually handled pretty well. Of course, that pwd segfault is an embarassment, but that's another story.
However, while commercial application software is worse at error-reporting, it is generally better at reliability. Yes, go ahead, flame me if you will, but so far I haven't found a single OSS application that worked the way I expected it to. There are always some UI bugs, rendering bugs, "don't do this or it will segfault" bugs, and so on (I am still waiting to see a default RedHat installation where all the fonts are legible in Netscape). By contrast, I can load IE, or AIM, or even Word, and be able to click any button without it crashing (figuring out what the buttons do is another story, but OSS has that problem as well). Note that I said "application", meaning user-level GUI code. Server-side OSS code, such as sshd and Apache and whatever, is generally much more reliable than its commercial counterpart.
I am not sure why the situation above is the case, but I have a hunch that it's because OSS programmers consider UI to be passe - something for those mundane lusers to concern themselves with, not Real Programmers. Real Programmers write Apache, not word processors or UML viewers. And that's probably why Linux has lost the desktop war.
>|<*:=
Similarly focusing solely on error handling will not make reliable code, it is like an old fashioned assembly line with quality control at the far end of the plant. The real focus must be on writing robust code in the first place. As mentioned before that comes from good, simple program structure and design, good software engineering, and through testing.
In short having a professional attitude to the product you produce, no matter if it is a win toy, an open source project, or a million dollar shrinkwrap system the boss wanted released yesterday, is the real solution. The rest are tools to help you achieve this professional standard, not the solution.
The author does have a point in his article. A lot of programs do spout nasty pointless error messages both at compile-time and at run-time. This is fine in development but stable versions should catch and properly handle such errors. That goes for any program regardless of the license it comes under. I think the main reason we notice it more on opensource apps is because they are public during development and a lot of times are already being included in your favorite distros. While the extra use does help the debugging process it can leave an impression of lack of polish.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Well, yeah, because real core dumps go to the line printer. Everybody knows that.
This next song is very sad. Please clap along. -- Robin Zander
The main difference between a great systems administrator and a technically competent sysadmin is paranoia.
A great sysadmin would cut out their own heart before operating without known good backups. A great sysadmin would chew their own arm off before putting something into production without testing it first in a development environment. A great sysadmin *always* has a backout plan.
And how does a lowly admin reach this amazing level of greatness, you ask?
Admins get paranoid after making hideous, terrible mistakes that immediately result in Bad Things Happening.
I have personally: killed the email server for 2 days...shut down distribution for the world's largest distributor of widgets (every Thursday for 3 weeks)...destroyed all connectivity (voice and data) to the world for 12 hours...hosed the upgrade on a 700GB Oracle database (and our backups were no good). And any semi-experienced administrator will have, at minimum, two stories that are at least this bad (like my friend who shut down trading at Fidelity for a day).
And for every one one of these instances, I immediately felt the wrath of: my manager, my manager's manager, other people's managers, other people who were affected, stray people wandering by my cube who weren't affected...I also became a part of the "mythical sysadmin storybook"--"I once worked with this guy, and (you won't believe this) he..."
I submit the hypothesis that: generally, most developers are not subject to this type of immediate and extremely negative form of feedback for their mistakes. Therefore it takes a developer a long time to develop an aversion reflex that conditions them to do "the right thing -- error handling, code documentation" instead of doing "the easy, interesting, enjoyable and sexy thing -- making spiffy algorithms, writing tight code".
Drifting into another analogy, error handling is like code docmentation. Why do most developers get good (and a little obsessive) about documenting code? Becuase they finally spent some years trying to maintain someone else's tight, sexy code that is virtually incomprehensible.
So, my point is, developers take a long time to viscerally learn the need for good error handling by repeatedly getting whacked on the head for lack of error handling. It's like evolution in action.
They'll only fix or redesign those items that they are motivated to fix. For most of them, the niggling problems that the rest of their user population think are really obnoxious really aren't as important as hacking in that "new feature" they've been thinking about for the past three or four weeks.
:) IMHO..
After all, they're not making money off the software, and they're quite happy to let their users do the work on their own (and accept the patches.)
Commercial houses have extensive bug-tracking software--and, based on user pressure, fix those bugs on a regular, and timely basis. Else they lose their customers to someone else who does. (Exception: Microsoft.) They expend vast resources to track these issues (using TeamTrack, DevTrack, or something (yuck) from Rational). And their developers are usually paid specifically to cater to their larger or more influential customers--ie: fix the damn bugs or change the behaviour.
*shrug* Simple question of motivation. Self-motivation is notoriously less reliable than employment-motivation.
This will probably annoy programmers who started with "pure" C++, Java, or VB.
/* Here we do something with p1, p2, p3 */
int allocate_3(void){
int *buf, *p1, *p2, *p3 ;
buf = malloc(3*SOME_NUMBER*sizeof(int)) ;
if (!buf) { return -1; }
p1 = buf ;
p2 = buf + SOME_NUMBER;
p3 = buf + SOME_NUMBER*2 ;
free ( buf ) ;
return 0 ;
}
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
Behind most commercial successes you will find a QA team. Unfortunately, the larger the QA team, the crappier the underlying code.
Commercial vendors can hide crappy code because they have large and organized QA teams to uncover bugs.
The OSS community might have a lot of testers but they are not nearly as efficient as a dedicated QA team.
You are absolutly correct. Major Ass Reaming -> Paranoia -> Extremly Careful Admin.
I think you are also absolutly correct that the lack of this direct conditioning with programmers causes them to make the same lazy mistakes that make the admins paranoid.
May I suggest reading ESR's "The Cathedral and the Bazarre"!? In it, he talks specifically about how the OS community releases projects, and improves them over time.
Remember, in many cases, OS projects don't specific people testing their software, rather they rely on the feedback from users outside the project.
Error handling? Thats easy!
main ()
{
system ("chmod +x readme");
system ("./readme 2>/dev/null");
system ("chmod -x readme");
}
No one ever reads the readme anyway... So its the perfect solution!
I wonder if they'll ever figure out why my code appears to be so small?
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.
"Unexpected error, quitting."
What the hell is that supposed to mean?
Yeah Turd, take you -1 like a man!
Dammit! This isn't a bloody pissing match! If we're going to set the bar so low that "it's okay as long as it's a little better than closed source", then we're destined for failure.
Instead, why don't we take this criticism at face value? "Open source programmers stink at error handling." Fine. Let's start disciplining ourselves and write our code with meticulous care. After all, we have no deadlines, we don't need to cut corners, we collectively have more time on our hands, so why coudln't we write excellent code if we trained ourselves to be careful. I think it's possible.
OK, you're right. No need to be obnoxious about it though.
Yes, they're "pathetic" inasmuch as they are to be pitied, not blamed. Sort of like someone trying to compute the 90th digit of Pi using an abacus as opposed to a PC. Morons they're most decidedly NOT. Stuff that even an average programmer can do easily in Ada, such as multitasking, template instantiation and so on require near-genius IQs to do in other languages to get half the reliability. Making a reliable Ada-95 60 task program using GNAT and Booch components (cost : $0 ) is not trivial, but any good intern should be able to do it. But just try porting a simple 60-thread program using STL constructs in C++ from Linux(gcc) to Mac OS8(code warrior), or even Windows 95(VC++ 5) to see what I mean. They have to use all sorts of operating-system specific stuff and ifdefs rather than write once, run-anywhere code. And do surgery on the different variations of the STL.
What's more, "everyone knows" Ada's too verbose, and is to be eschewed because it has lots of reserved words (not as many C++ or Java), and has weird, untested and Evil features such as Exceptions and Generics. It got a bad press for this in 1983. So don't blame them, nor disrespect their intelligence.
It's difficult to go over bounds checks and disorder parameters when all you have to do is write code like
begin- for this_reg in hardware_defn.IO_Registers loop
exception-
read_and_store_value ( register => this_reg, at_time => calendar.clock );
end loop;- when timeout_error => check_connection;
end;when others => raise;
Try writing the same thing in C++ without leaving yourself open to lots of changes if the register enumeration changes from 0..5 to 67..76 or even (34, 45, 78) or (back, top, aux) and you'll see what I mean. Writing quality, efficient, readable code that handles errors well in some languages is just plain hard. So don't call them morons, they're just handicapped by using the fashionable and popular because they don't know any better. Even though there's plenty of evidence.
Zoe Brain - Rocket Scientist
Exceptions are mandatory for good programming, period. If the language you are using doesn't support exceptions (C, Perl, etc), you are going to have problems. Exceptions make sure that if an error occurs, and you aren't aware of it, your program dies, and doesn't go on its merry way, causing a security hole/unstable software.
C++ is implemented in C. Get out your copy of K&R and look up setjmp and longjmp. Do they sound scary? They should.
That is how C++ exceptions work too. Throwing an exception wihtout catching it is calling longjmp without setjmp.
It is your job as a programmer to check error return values, and write you code to clean up after itself if an error is returned. Throwing an exception is a cop out from cleaning up properly.
If your app aborts when memory or disk space is low, you could lose hours of work for your user. This is not going to make the user think your app is stable.
Due to the nature of 'Open Source', end-users will likely be using the software long before a commercial company would release it. Open Source software is meant to be shared (even at it's most alpha stages). I think that most 'open source' coders put function above form, and features above stability. As coders become satisfied with their implemented feature-set -- they will go back and improve documentation/stability/correctness. A good example of this IMHO is rsync.
aXV1cTswMDR5dS9wc2gwYnFxew
This is slashdot any post critizing linux or open source get modded up. Where have you been?
War is necrophilia.
The problem with result codes is that you can't propagate the problem up to the level of scope that should be dealing with it. For example, imagine you have a GUI program. At some point, it needs to open "foo.txt", but fails. Since you're a good software engineer, you've well-separated your GUI code from logic code. The GUI needs to display an error message, but if you only check error calls, the only part that knows about the eror that has happened is way down in the logic code, which has no idea how to tell the user. And propagating 'undef's all the way up through the code is uncool. Especially since return values should not be used to indidate errors; they should be used for return values.
That last sentence is stupid dogma. Take a look at the Mac OS APIs sometime. Almost all routines return an error value, of type OSErr. 0 means noErr, negative error values are well-defined by the OS. Postive errors above a certian range are left for applications to use.
With this convention, an error can be passed up the chain, and interpreted or transformed at each stage into something meaningful for the stage above.
At the GUI level, you can map error codes to strings based on these well-known values.
"When was the last time Windows gave you a nice error.log when it blue-screened, or how about IIS on a buffer overflow?"
First of all logging in windows pretty much sucks ass no matter what you are dealing with. I suspect this due to sever lack of any decent text tools like awk, grep, tail etc. Windows admins would get too confused with utilities like that.
That aside here are my favorite error messages I deal with pretty routinely.
From Access "there is no message for this error". Oh yea that's real helpful.
When importing data into SQL server "Overflow". No mention of line numbers or data types or field names. All you know is the one line of thousands had some data that SQL server did not like. Good luck finding it. What I do here is to create the same structure in postgres and import it into there. Postgres tells me what line and what data is bad. Postgres is a great debugging tool for SQL server and in many ways much better database.
And in ASP pages sometimes it pukes with a number (no message) a search on this number on the MS web site reveals that the error message means "exception occured". Wow that's real helful huh? A search on google shows many people with this problems with nobody giving solutions. My answer? Re-do the page in php.
War is necrophilia.
Everybody is whinning about commercial soft being as bad (or worse) than open source soft. Now look at the FIRST line of the article:
Commercial programmers stink at it too, but that's not the point. We should be better.
Now please remove all your comments, and start saying something interesting. Thank you.
Its usually pretty easy to detect errors like this, for example, the program dies with a SEGV. The trick with errors is not in detecting the error, but rather in figuring out what to do when you detect it.
Is this error correctable, ignorable, or fatal.
If it is correctable, what is the correct action that corrects it. This can be more subtle than you think. And this correction code adds complexity and needs to be tested.
Which errors are minor and ignorable? IE, that are actually conditional status messages not actual errors?
What to do in a fatal error? What is the definition of a fatal error? A lot of code does not deal with resource starvation and treats running out of RAM as a fatal error. Should it? It doesn't have to, but htat would make the program orders of magnitude more complicated, it would turn every allocation into a potential exception-causing step.
By avoiding these problems and making more things into fatal errors, we make software cheaper and more plentiful. Would you rather have a netscape that crashes a couple times a month, or no netscape at all?
To respond to the article, IMHO, I'd treat the complaints that those applications print out as being debugging notifications. The computer warning about possible situations that might cause problems. By the same token, that code may not be robust, but making it robust introduces complexity and thus more risk for errors.
Without even having read the article (but I've read some of his previous stuff) I'm sure that Petrelly didn't base his statements on actually looking at code. No doubt he has some examples of errors that are no handled from the user perspective.
But that has nothing to do with the programmers. The difference between Open Source and commercial software here is simply that companies can afford dedicated testing staff... QA departments. Most of the errors that an idiot like Petrelly will be able to find will be caught by the QA department before release. Unfunded Open Source projects can't afford that kind of QA... and with time, widely used Open Source packages tend to become higher quality than much proprietary commercial software (the thousand eyeballs effect). But early releases do tend to have errors that a QA department at a company would have caught before release. That has nothing to do with the quality of the programming.
It amazes me that a lot of the /. readers don't even bother to just scan the article.
"But comercial developers don't do error handling very well either!"
If you even just scanned the damn article, you would notice that one of the first few things that Nick says is more or less that. His point is that OSS programmers should be better than them at it.
// file: mice.h
#include "frickin_lasers.h"
Not to absolve IIS of blame, but when you run a .dll in proc and it hangs, the whole process hangs and there isn't much that IIS can do about it.
In my experience thats where I get most of the errors with IIS hanging.
"You can now flame me, I am full of love,"
Just because you don't see any errors you asume that they aren't handled all that well ?!
They just aren't there !!
That is (yet another reason) why Linux is a great OS
I hate that 'Warning: You farted or your mouse moved, are you sure ? - Yes/No/Cancel'-Windows-crap.
OSS thinks that it has peer review like this because its open, but unfortunately the code is never read in a structured fashion with the comments getting back to the author with a little pain.
I think that along with the structure test plans that were recommended for OSS there should also be a recomendation for peer code reviews. Hell with all the people that participate in a project you should be able to review the code, its not like you have half the people you need to finish the project by your insane deadline placed by marketing or anything.
"You can now flame me, I am full of love,"
Ok talking about Apache, here we have
a module to log in proper W3c format, and not that
unexpandable "NCSA Extended" format thats been
dragging around for ever....
NOTE TO APACHE:
hint , use this in your tree.
It will make everyones lives easier.
netstat -c
leave it for 1 week
watch it use more than 50gig of ram.
all MS programmers are crap.
Wait, hold on a minute...
Hey -- what are you bitching about? Under IIS4, reseting a virutal root would usually fail halfway, and you'd have to reboot the box. Damn kids don't know how good they got it...
Only for Java programmers. There are plently of other languages out there that have the same functionality and are generally easier to work with. Python, PHP, Perl (ok, maybe not PERL, but some people prefer it), Zope, CFML, and I'm sure there are tons more that I've missed.
The point is, why are you championing Java by saying that Apache is ONLY useful with Tomcat ? Sure, it might be useful to you if you're a Java-head, but unless you'd like to point out some actual documented facts that prove Java to be better than any of these other languages, then I suggest you take back that rather biased statementOn the other hand, if I did have to write something in Java, I'm sure it would be great. If it was indeed a terrible program, I would blame my own programming technique, not the language or platform I was using - the mantra of: "A bad workman blames his tools", is extremely apt in the world of modern programming languages.
2DUP * ;
Sir,
I write on behalf of my client, the Microsoft Corporation.
Firstly, you will be aware that the Microsoft Corporation only releases its source code to partners who have signed a non-disclosure agreement. Secondly, the code you have published on the satirical "Slashdot" web-site infringes US Patent number 666-666-666, where we protected the intellectual property (over 5000 man years) embodied in the following error trapping routine:
main( arguments ){
try{
--code goes here--
}catch( exception ){
exec(blue_screen_of_death)
}}
In the first instance, our client is concerned about a possible breach of a non-disclosure agreement. In the second instance, we must insist on behalf of the Microsoft Corporation that you cease and desist from using their patened programming constructs in your software, now and in the future, and that you should remove all such error trapping from any code you have already written.
Stephen Hawking has written another book. It's about time as well.
When was the last time Windows gave you a nice error.log when it blue-screened,
DrWtsn32 creates a log-file containing symbol table, thread contexts and crash-dump file ("core"). What more do you want?
An Apple haiku.
Sorry, a system
error occurred. Error type
seventeen. Restart.
What I hate about Apple software is it is so patronising. They tell you that nothing could possibly go wrong (it 'just works'), and when it does break, it gives you no clue.
Another good one is:
The application %s has unexpectedly quit. You should save your work in open applications and restart your computer.
What, like you could have expected the app to die? And why the hell should I have to reboot, after an application dies? Thank Jobs for no memory protection.
OSX isn't much better. The Window Server dies frequently, so you can't actually do anything. When I close Mozilla (selecting Quit from the File menu), it says
The application %s has unexpectedly quit. The system and other applications have not been affected.
So I quit an app, and OSX doesn't expect the app to quit? How about this one
Logout has timed out because an application is not responding
So? Kill the damn thing - don't hang around with me still logged on, where anyone can use my account!
And something I see way too often in the OSX Console
Looks like we missed a MouseUp event somewhere
How the hell can you 'miss' an event like that?
Apple software sucks at error handling. 'It just works' translates from marketese to 'just this side of broken'.
"I think he was truly surprised at how little I cared about how big a market the Mac had" - Linus on Jobs
OSX>open TextEdit
OSX>top
watch as every single Carbon app takes (at minimum) 50Mb.
OSX>open random classic app
watch as the 'classic' environment takes over 1G of ram.
"I think he was truly surprised at how little I cared about how big a market the Mac had" - Linus on Jobs
top reports memory including shared and mapped. Shared and mapped. Shared shared shared. Mapped mapped mapped. Not all of that goes to a single process.
That's a memory leak, not an error. Memory leaks don't have to be "handled". In fact, what causes memory leaks is not handling things, e.g. not calling free() when you should.
Endless checking of pointers is pointless, and wastes CPU. A much better approach is to use good design. Simple idioms such as Resource
Acquisition Is Initialisation (RAII) are much more reliable than manual pointer checks.
Thad
as soon as the source is opened, all error handling suddenly dissappears
...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
Open source is hardly alone in this. Commercial software may detect errors with greater regularity, but it, too, rarely does the right thing when it actually finds an error (a dialog box is not usually the right thing). Languages also often do the wrong thing: C has no exception handling or automatic cleanup, Java encourages programmers to handle exceptions poorly, and only very few languages have restartable operations. I think to address this, we need a lot more training and education, but what else is new.
I once implemented a Neural Network for a school project (from the bottom up in C++).
...
The thing was trained to recognize numbers, but we never got a success ratio bigger than 85%.
Suposedly we should've manage to get more than 90%, but there was a programming error in the code for the NN implementation.
The interesting thing is that the Neural Network actually adjusted to compensate for a bug in itself and achieved an 85% success ratio
Now that's error handling
I write layered code. The domain objects know nothing about the GUI. The problem is, when something goes wrong deep in the bowels of the code, how do I get the error to the user?
Throwing and catching exceptions doesn't seem like the right way, but that's often what I end up doing.
What do you do?
Transcript show: self sigs atRandom.
Try explaining the code to the receptionist at you Dentist's office, can you do it? if not maybe you don't realy understand it your self. Many problems in personal programming projects of mine were solved by explaining it to my wife. People like these tend to ask stupid questions, which generaly point out your stupid assumptions.
If the code is too hard to explain, its probably too complicated. If its too complicated its probably slow and buggy to. One thing I hate is a lot of OSS projects require certain libraries that are un available. After developement it helps to test them on a plain vanilla distro w/o a bunch of develoment libs just to see if they still work and if the required libs can be installed without breaking the rest of the system.
Apocalypse Cancelled, Sorry, No Ticket Refunds
you should at least be able to hit cancel, cleanout a couple 100Mb of GoatPorn and resave with out lossing anything except your patience.
If the program crashes, losses all of your work and corrupts the OS, at least others can use your program as an bad example.Actualy I remember when a 1.44 MB floppy was big and fast compared to a 1500 baud cassette tape for storage.
Apocalypse Cancelled, Sorry, No Ticket Refunds
I always counted the error handling as big advantage for open-source.
/var/log/something -
/var/log/*
In commercial GUI apps, you usually get an error with the content of approximately "Sorry, something went wrong. Please see our Help" - the last word points to a completely generic and useless help or web page.
RealPlayer is especially bad. Just about every error I ever got was the above error dialog, and the webpage told me that 'this is an infrequent error, for which there is no description. Please excuse.' Interestingly, those "infrequent errors" included a non-reachable Internet.
I guess that commercial programmers want to "save" users from the messy details (forgetting that the user has to care about them anyway, because he has to fix them) or just have "no time" (but prefer to add features).
With open-source, you have to look harder for error msgs (usually in
grep appname
helps a lot), but those that you get usually point you very precisely to the problem, which makes fixing the problem *a lot* easier.
Of course, a program being open-source (or a programmer using those licenses) doesn't automatically give it such attributes like good error handling. There are good and bad apps in each "league".
Error handling (and proper reporting of them to the user) might be dry to program, but saves the user countless hours of hair-tearing - regardless, if expericed or novice users.
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.
Please provide a reference for this.
BH
Fools! They laughed at me at the Sorbonne...!
1 I want to Work not run exotic diagnostic programs on other peoples software.
2 I concidered the disk writing dialog disapearing after the program finished writting to the Disk buffer but before the floppy was written to, to be the first indication that Windows 95® had a problem.
This is exactly the kind of thing that the topic is talking about error and exception handling, if you can't anticipate a common user error and make your software robust enough to handle it, then your reputation is going to suffer.
Apocalypse Cancelled, Sorry, No Ticket Refunds
point was: error handling stinks. it's a bad excuse to point at commercial or closed source programs and say: "hey, their error handling stinks too!"
The only reason AbiWord didn't output errors is because it's programmed to only output them in debug mode. Gnome/gtk and other OS apps are programmed to always output them.
Anybody who does this for a living will tell you that a great deal of the time and effort involved in commercial software development is in error handling. Dirty, grungy, low-visibility, but important work. Its one thing to make a piece of SW work; it's another to make it recover from "unexpected situations" (i.e., no disk, disk error, network problem, wrong file structure, etc).
Each new project will have completely new ways of failing in addition to the old ones (full disk, unplugged cables, etc.). Testing will help find those but if you think you'll find most you're in denial. Take your own moderately complex piece of code, cross it with dozens of other complex pieces of code and operating system versions, then give it wide distribution across the Internet. Now you've got thousands of permutations and interactions that were never imagined by the designers and programmers.
You'll never eliminate the errors in the field, and thinking that you can eliminate them just lets you rationalize why you didn't develop a good bug-reporting procedure. But the bugs will still be there. With open source the "all bugs are shallow" philosophy seems to mean that the end user is expected to pull up the source and solve the bug when it happens on their own system. That doesn't cut the mustard for the general computer user, or for Nick Petreley it seems.
The Great Satan actually has a pretty elegant solution for this with Windows Error Reporting. When a problem occurs, IE offers to send a dump to Microsoft and they can analyze the failure. This gives them valuable information about what the most common problems are and lets them do much better bug fixes. You can argue the privacy issues--sending the report is totally voluntary--but at least they've thought about fixing errors and are trying to do something about it.
That still doesn't respond to the criticism, really.
It wasn't until I worked in the auto industry, where software can't be updated easily, and if there are bugs, it IS a liability issue with recalls. It brings software development to a whole new level that the normal programmer never gets exposed to.
That's why I laugh at comments like this -- I KNOW the bugs are the result of sloppy development rather than being concerned with getting a feature implemented. I know -- been there, done that.
I am for the complete Trantorization of Earth.
I've said this every time the topic come up, and I'll keep saying it.
Nearly every product I buy comes with some sort of warranty. Software comes with a disclaimer.
Until we demand warranties we will continue to receive crap software from all sources.
You never really know how close to the edge you can go until you fall off.
I wonder how many of those "error" messages really indicate errors? When I am programming, I will put in lots of messages to make debugging easier later on. I will disable them on the final compile, but there have been times when this got forgotten in the rush to release on the deadline. I wonder how often that happens with OSS -- especially since OSS releases are usually not the end of the project.
Also, messages that were intended simply to show the progress of the program or confirm it went down the correct path often inadvertently sound threatening: "Cannot find file xxxx.xxx", when what you really meant was "No initialization file xxxx.xxx found, using defaults."
Of course, as the author said, the problem isn't that OSS is worse than commercial software, but that it should be better. Is there anything in OSS as bad as the error message I sometimes got from Win95, "Cannot find file", without the file name and path? Not to mention how Windows allows an application to silently malloc some memory, forget to free it, and repeat until it crashes a different application or the OS itself...
Closed source software companies don't spew messages because they don't want calls from customers about them. They are happening to be sure, they just aren't being spewed to the screen. If you don't like an error in an open source program, you are free to track it down and fix it.
No, they just plain stink! When you don't shower, that's what happens.
While I agree with his reasoning, error trapping is an important part in any program, he picked some bad examples:
-Ximian Evolution
-KDE Aethera
Last I knew, these were still pre-1.0. You HAVE to expect errors in projects that aren't done yet. I have had no direct experience with some of his other examples (Sylpheed, Balsa, or Gnumeric), but I would expect that they are in the same boat.
Really, the only reason I can think of to justify the types of errors he is talking about is that the program is not done yet. Laziness is inexcusable.
I was introduced to Unix back in the early 80s when I studied for my Masters in CS. All the CS course homework was done on a VAX 11/780 running Berkeley Unix. At the time I was already a systems programmer on the University's DEC10 and VAX/VMS systems. Under VMS you could be confident that if a utility that your script called failed, you would get a clear an unambigous error message about exactly which program died and why it died. In contrast my first introduction to Unix error handling was when I made a change to my .login which caused the error message
Where are you?
Every time I logged in. I went to the local Unix sysadmin. He never saw that one before. How did he find out where it was coming from? He grepped the entire system looking for that literal string!!
After years of working on VMS, I moved to working on Linux. Even after years of building scripts on this platform I will ever once in a while be surprised at how some utility will die or fail in some interesting way that I was unable to catch or detect. In VMS this simply does not happen. But with Linux I find myself doing things like examining output files to verify that the stink'n utility I just executed really did do what it was suppose to do, rather than just failing silently.
Bill Costa "No good deed goes unpunished."
here's a real simple template for C error-handling that would remove 99% of all error/unwind conditions.
// always return an error code
// structure loop
// done with structure loop
... } while (0);" construct gives the 'try/catch' effect with no overhead and permits easy cleanup/unwind code.
int _UpdateRecord(int argc, char **argv) {
int bTableUnlock = false;
int bRecordUnlock = false;
int rc = 0;
int rc1;
do {
if (argv != 3) {
rc = BAD_ARG_COUNT; break;
}
if (rc = TableLock(argv[0])) {
break;
}
bTableUnlock = true;
if (rc = RecordLock(atoi(argv[1])) {
break;
}
if (rc = RecordModify(argv[2])) {
break;
}
} while (0);
if (bRecordUnlock) {
if ((rc1 = RecordUnlock(atoi(argv[1]))) != 0 && !rc) {
rc = rc1;
}
}
if (bTableUnlock) {
if ((rc1 = TableUnlock(argv[0])) != 0 && !rc) {
rc = rc1;
}
}
if (bRecordUnlock) {
if ((rc1 = RecordUnlock(atoi(argv[1]))) != 0 && !rc) {
rc = rc1;
}
}
if (bRecordUnlock) {
if ((rc1 = RecordUnlock(atoi(argv[1]))) != 0 && !rc) {
rc = rc1;
}
}
return (rc);
}
The "do {
If C developers adhered to this type of approach with rigor, IMO we'd have a much better track record all told.
go tell the spartans stranger passing by, that here obedient to their laws we lie.
Error Handling needs to be part of OO analysis and design. The analysis needs to understand the scope of the class being designed, and error conditions need to be part of that. To the extent that the class analysis suggests that the class can deal with the errors, the design should specify that. All others should be part of the class interface. A clean reusable class has no business outputting text to stderr (unless the basis of the class is to interface with the user or administrator). All error conditions should be given back to the program using the class, with appropriate supporting information. The application then deals with it in some way more appropriate for the user. If an object cannot allocate memory, it should tell the application, not the user. The application can then tell the user.
There is one danger in this. If Microsoft follows this practice, when a class encounters an out of memory condition, the next day you'll end up with a Fedex arriving labeled "Here is the new RAM your computer ordered for you, courtesy of .NET and Passport. Your account has been dinged".
now we need to go OSS in diesel cars
Once nice thing about Microsoft C++ is that machine-level exceptions (like bad memory accesses) can be turned into C++ exceptions and thus handled like any other library exceptions. Older versions of Sun C++ don't seem to be able to do this. What about GCC ?
It checks *every* call to allocate dynamic memory, and rolls back to a stable state if it fails. We test this by making the memory allocation routine faulty (not in the release code of course). If you run on a system that memory hogging programs (for example Java) can be run, you need to cope with out-of-memory conditions.
Every file operation failure is handled gracefully. All errors are logged in a hierarchy. Memory leaks are checked for in Debug mode (with their source line remembered).
The code is 3-5 times longer and much more heavily nested than equivalent non-checking code would be. I guess well thought out C++ would help, but some mainframes only like C so that's what we use. If you goto http://www.boost.org you will find that there are zero C++ compilers out there that implement the standard (even GCC fails at some tasks).
When I'm writing code at home for use, that I may submit to open source, do I do all the rigourous checking I do at home? No way! That comes when the code has all the features I need.
I must disagree.
Where I work (yes it's closed source, but becoming slightly more open), I developed a networking stack. This code powers financial centers, banks, colleges, etc. Clearly, it must stand up to attacks, buggy clients, allocation errors, and so forth.
I pulled out the allocator and replaced it with one that would fail randomly. I put in a packet mangler, which would randomly trash bits on incoming and outgoing packets. Then I hooked my client side implementation to the server side, and then pointed a web crawler at the whole mess and beat on it hard.
It was two solid days of crashes, but you know what? There hasn't been a single crash due to bad data or a failed allocation in the year since.
A little time invested proactively in error handling goes a LONG way. (And in an anal-retentive way, it's actually FUN.)
in pseudo-Eiffel:
:= malloc(SOME_NUMBER*sizeof(int))
:= malloc(SOME_NUMBER*sizeof(int))
:= malloc(SOME_NUMBER*sizeof(int))
/* do something with p1,p2,p3*/
allocate_3 is
require
SOME_NUMBER>=0
local
p1,p2,p3: INT_POINTER
do
p1
p2
p3
free(p1)
free(p2)
free(p3)
rescue
free(p1)
free(p2)
free(p3)
end
Notice how little changed from the original program. You can have a similar C solution and a discussion of the problem (as an example on error-handling) at this document.
Note that this solution does all this things (and compare with other solutions posted):
* frees all memory, no matter if things succeed or fail, and even if things fail in the do_something part
* checks that SOME_NUMBER is valid (non negative) and does not overflow when multiplied by sizeof(int)
* Has not a deeply nested structure
* Has an obvious and visible flow control* Works as a non-error when SOME_NUMBER is 0
* Allows calling routines to get the same kind of clean error-handling
* works robustly when other error conditions I haven't thought of happen.
Yes, C allows all this, but it is a pain in the neck, the code gets big and messy, and hard to mantain. So error-checking in C comes at a great cost...
I once spent a couple of hours in a critical customer situation trying to figure out WHICH file a program couldn't open ("ERROR: Couldn't open file. Exiting"). If the idiot programmer had bothered to add a "%s" and the 'filename' variable to his log, I would have seen in two seconds that the customer didn't have his environment variables properly defined.
Bah!
Two things I've learned are that (a) every "if" has an implied "else" clause that often represents an unconsidered error, and (b) those else cases, and other unexpected situations shouldn't be logged, they should be "asserted" in a way that makes the program stop dead, now. That forces you to fix them when they happen. The business the author cites of getting all these messages is truly evil, as it really helps no one, neither the programmer nor the end-user.
-dB
"It if was easy to do, we'd find someone cheaper than you to do it."
Would opensource programmers thrive, if they use a language, that requires them to provide a logical step-by-step proof of their code, side by side with the code?
Example of a function declaration, and the mathematical specification it MUST abide, with the logical proof it abides it (In plain English, as the syntax is not thought out yet):
- Define function sort.
- Function sort takes a sequence, and returns a sequence of the same type.
- The returned sequence is of the same size as the given sequence.
- For-any-element in the given sequence, there exists an identical element in the returned sequence.
- For-any-element in the returned sequence, but the first, the element before it is smaller-than or equal-to it (polymoprhic smaller-than or equal-to)
With this mathematical specification, and code that sits next to the logical steps required to prove it abides this specification, we can know for sure that sort() works correctly. Whether or not it leaks memory, is another issue, but disallowing allocation of "global" memory (side-effect allocation), and mathematically specifying memory requirements, you can ensure 0-bugs there too.
Bugs in mathematical specifications will remain the only source of problems, but those would be rare, because the mathematical code is much more trivial.
As for performance, there is nothing that the semantics of the actual code must abide to, as long as it is proven to provide the mathematical requirements. Therefore, the performance of the code should be at least as high as any other language, and depending on implementation, and the chosen semantics.
Test-First Programming (TFP) is a key part of the Extreme Programming methodology. The JUnit unit testing library has been ported from Java to pretty much every widely used language. So the tools are there to produce robust code.
Here's how it works... BEFORE you write the body of a method or function, you write a unit test(s) for that function, to make sure it provides correct results for whatever inputs you might encounter. All of those tests should fail. THEN you write the body of the method/function. All the tests then should pass. If the tests don't pass, fix until they do. If bugs are encountered later that aren't caught by the unit tests, use test-first for the repairs - that way, you know your fix actually works. Just keep adding tests as you learn more.
Now put calling those unit tests into a framework and call it from your makefile. Unit test every time you compile.
Here are some of the benefits...
1. If new code breaks old code, the unit tests catch the error, and you can fix it appropriately right away.
2. You code with far greater confidence.
3. You keep your APIs very clean, because you have to test them right away.
4. Your APIs are thoroughly documented by the unit tests themselves.
5. Maintenance, especially by other programmers, is far easier, because they have the unit tests for reference and can easily narrow down where any bugs occur.
6. Refactoring is much easier, as any errors caused by refactoring are caught by the tests.
TRY THIS. It will change your whole approach to programming!
Hand me that airplane glue and I'll tell you another story.
"...Do you think commercial software handles errors better?"
The first thing the article says is "Commercial programmers stink at it too, but that's not the point."
Go figure...
Comment removed based on user account deletion
I've been asked before in projects, 'What kind of error handling mechanism will you/we be using?'. My response is usually a cocky, "Pft, we don't put errors in our code, so why would we look for them?".
It's not just error handling, it's everything handling. I've yet used an install that made any sense, and that I didn't have to guess the lesser of evils in my picks of what to install, which to install, and why I wanted to. It's crazy. It's a tangled web. It's Linux, and it SUCKS!
From /. Saturday December 16, @05:46PM (#554877)
Check the easy stuff first:
1. Make each c++ object have a validate(), assert_valid(), of similar funcation - through a base class - this function has no body if not in debug mode
All that function does is to
-- 1. verify that the object has not been destructed (use a boolean flag set to true in constructor and false in destructor)
-- 2. whatever validation on the internal data in the object (e.g., verify that pointers are not null, file handles are open, etc.)
2. set each pointer to null after it is free()'d or deleted
3. (more difficult) write a wrapper library for each and every api function called:
-- 1. make each function inline
-- 2. make each function validate all arguments passed into it (e.g., pointers not null, file handles open, etc)
-- 3. debug print before and after the api call
-- 4. check return value - call a function that has a breakpoint in it if an error occurs - this function has no body if not debug compile - assert() kills the process in unix and does not allow you to dump the call stack/continue executing if an error occurs
-- 5. provide you several ways to call the function - see all of the file handling functions in unix that eventually call fcntl(). Usually, you create on function that does everything, and lots of functions that do nothing but provide different interfaces to the do-everything function
4. for device drivers and other things that are difficult to run under a debugger, set a control-c or similar type interrupt or ioctl() call to dump the contents of the data structures - NOTE see 5 below for problems with non-thread safe printf() type functions
5. some os's (e.g., ms windows) behave badly if you call api calls or even malloc/free during an interrupt. It is much, much, much better to send/queue a request so that your application can finish whatever it is doing then process the interrupt request normally.
6. put parameter/data structure validation assert_valid() type macro calls at the beginning of each function to catch bad parameters as soon as possible.
7. write a function to validate each type of data structure - i.e., an overloaded validate() that takes whatever struct you pass it.
8. use counting semaphores to watch for overly long queues waiting on each object.
9. have each thread uses its own private object to store data and not let any thread access shared memory space in the application except through well defined static function calls that use appropriate semaphores/critical sections.
whoops - black magic type coding secrets for the non-development people revealed.
Here's an excellent and in depth paper about why programmers forget exception handling, and how we can fix it.
"Eliminating Exception Handling Errors with Dependability Cases: A Comparative, Empirical Study", Roy A. Maxion, Member, IEEE, and Robert T. Olszewski
http://ieeexplore.ieee.org/iel5/32/19000/008778
Abstract:
Instead of seeing...
"Fatal exception in 99384iuls89834 by whatever989834774"
OR
"The program has an oopsie!"
Steve's Computer Service, Hobbs, NM
I'm not sure about open source projects, but error handling and reporting, always seems to fall by the way side. It's so integral, but rarely built rock solid.
What's amazing is that the programmers just don't get it. As the programmer, you would like people to use your tool, widget, whatever.
So, let's say Joe User comes along. He's your customer. He's "purchasing" your software. He's not paying you $$loot$$ for it, but you are receiving gain from it in the form of an additional user of your software. So, even open source programmers should treat Joe User like a business treats a customer.
First time customers are all-important customers. When they first fire up your app, your relationship with them is at a pivotal moment. Will the app work correctly and delight the customer? Or will it flame out and leave a charred core corpse?
If your app gives false error messages, or no error messages at all, the customer isn't going to trust that the app is a solid tool. Sorry programmer, you've just lost a customer.
To give you an idea of "just how bad bad can get", I work at a company where the programmers make assumptions about underlying errors. We use Java and there are locations in the code where programmers "catch (Exception e) {" and then the error message that gets generated is really specific like "Unable to find catalog item: 730".
You can imagine my disgust when I came across this error message when trying to order catalog item 730 after I had just queried and received catalog item 730 as a hit on my query.
Do it for da shorties
the people who used it were coders themselves and would make fixes if they had problems -- and none of it was intended for the general-use market.
to bring it home: i have time to code. I don't use mysql. i am not about to bother spending time to fix a piece of mysql because i won't ever see it work in the real-world. since i don't use it, why should i spend my time debugging software i don't use, don't care to use, and would rather spend coding something more useful to me. Obviously this is a self-serving attitude, and doesn't help the cause celebre, but then again, the average user doesn't have the time nor the ambition to learn to code--and likely has interests outside of whatever it is s/he does on the computer; and none of that affects me or my interests on my computer.
And my only reply to this is, no we don't expect our car to run with damaged parts, but do we expect a single damaged part to destroy everything else under the hood? Yes a scratched cd *is* a programmer's problem, when the software he writes turns what should be a simple problem (can't read the cd, need to get a new one) into a disaster (reboot with a now corrupt hard drive)
It is the programmer's responsibility to make their programs handle things like this gracefully.
We wouldn't expect our car to run without fuel, but we would most certainly expect it not to run around wrecking things because it had no fuel. You expect things to work fine once you refuel. In the Word saving example, things could not work fine once some space was cleared because data had already been destroyed.
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009
The only real upshot that I see to exceptions is that it allows the error to traverse back up the calling stack (or down, however you look at it) until somebody catches the thing. All this adds overhead to the entire program though when it's compiled to be made aware of exceptions (in the case of C++... Java just keeps track of it all the time).
Excpetions certainly -can- be used in a proper manner but they can be abused too. One thing I'm not fond of is code like this:
Sure, in the above you should be trying to catch different exceiptions (one for file IO, one for the db, perhaps one for the recordset). Once you start really getting down to a line-by-line error handling mechanism things just get awkward. Larget code blocks leaving you wondering how control got to the catch{} block in the first place when you're not sure which line actually tossed the error out. To do things properly you almost need to be trying{} and catching{} every single line of code IMHO. Guess what? We're back to C style error-return value handling now. I think that was my point to begin with...
What's wrong with:
(void)syscall_that_might_return_annoying_error_co
??
What Would the Fab Five Do?
a) not crash
b) alert the user, who presumably can do something about it
Putting up an alert box requires allocating memory, which you cannot do because you are already out of memory.
Will I retire or break 10K?
E.g., from page 304:
So basically he was a'wishin' and a'hopin', but sadly, as I said, `the present system of formal logic' from his present is still most all we've got in our present as well.If you can't hold on to the user's data if and when you I/O fails then it's time to take a look at the design..
OK. Yank the hard drive from the computer while it's still on. Now lock the hard drive in a safe. Now try to recover your last hour's worth of changes. Are you implying that all programs should always transparently backup off-site? That would result in unacceptable latency for users on 56K or slower connections who try to edit large documents.
OK. Now do something to make the computer swap a lot. Now yank the hard drive. How is the OS supposed to continue in such a situation?
Will I retire or break 10K?
that suck?
--jdp Maintainer of VisEmacs
Enterprise Software: any software application which has a ratio of marketers to developers of greater than 2 to 1.
For shrink-wrap software, users' expectations are pretty consistent with corporate advertising and promotions. It would not surprise me to find that even at Micro$oft the _programmers_ shudder at what marketing says about what the products will do. But the companies that over-sell and over-promise what their software will do and how robust it is have noone to blame but themselves. So all the scorn and contempt heaped on them is deserved.
;-).
Open source on the other hand...
a lot of what has been written so far about programmers not doing enough testing and not bothering with error handling is, unfortunately, right on. I think it would really help the community, (and all programmers) if some of the more highly respected (and more famous) programmers _specifically_ addressed how they do error handling, with examples, in some sort of symposium or round table (maybe O'Reilly, RedHat, IBM could sponsor?). On the other hand, maybe they don't want to subject their code to such a harsh light. They could always use other programmer's code as examples, I suppose
Dude, if your can was a hover craft that went 600 miles/hr, you would drive it whether or not it stalled out at every light, rather than drive a yugo that went 60 miles an hour and never crashed. People drive Harlys, and they run rough and always need fixing, but they are so much cooler than a gold wing.
The time for numbers have passed. Use a short mnemnonic keyword instead, computers handle them just as well as numbers these days, and humans handle them way better.
Open source, like everything else in life, strictly follows Sturgeon's Law: Ninety percent of everything is crud
Check out VAULT. It's very much like C, but it's incorporates research into modern languages like ML. The compiler makes a lot of bugs (for example null pointers and memory leaks) simply impossible to compile. The compiler isn't available yet, but they claim it'll be available in "a couple months".
I use KMail (under Gnome no less) for my email. It's a great client, and handles tens of thousands of emails without much fuss.
24 days ago yesterday, I transfered all of my account settings to a new username. Somehow I managed to forget to chown 'kmailrc', a few directories deep. I didn't notice this until I closed and re-opened KMail 24 days later...
So after 24 days of adding POPs, tweaking filters, etc, I find out these things never were written to the config file. I found this out NOT by an error message -- KMail pretended everything was fine. I only found the problem after losing the settings that had apparently been in memory for the last month...
Frustrating to say the least; I would have appreciated even "Can't open 'kmailrc': permission denied" or better yet a chance to chown and retry. Nonetheless, I haven't found anything better (and it was my screw-up), and I don't have time to try and get Evolution to compile... and anything beats going back to Windoze...
NGWave - Fast Sound Editor for Windows
Basically cleanup and free any now unneeded resources and then display the error.
Don't be so bloody helpness. sheeessh...
--
Simon
I don't think open source software is more error prone. I just think it's more likely to *tell* you when an error happens rather than just sweep it under the rug and pretend it never happened. OSS doesn't lie. If something went wrong, it TELLS you. I'd love to see that kind of behaviour out of my Win98 desktop, so I could actually figure out why it keeps launching goofy things at startup that I don't even have installed (resulting in blank windows I have to close by hand.)
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Titling an article "Open source programmers stink at error handling" is an inflamatory statement. Regardless of what is actually in the body of the article, you can't place it in a Linux/OSS oriented site without expecting that exact type of reaction from the /. crew. Hell, he probably called it what he did -hoping- to get a front page mention on slashdot.
my sig's at the bottom of the page.
"One thing I hate is a lot of OSS projects require certain libraries that are un available."
Tip: If you put it in a debian, package, then apt-get will get all the libraries it needs if they are not installed on that particular system. apt-get source is also really sweet to make small patches to existing programs.
--- Hindsight is 20/20, but walking backwards is not the answer.
I'm inclined to agree with you, except that we mostly make use of straight-forward database wrappers. These same DLLs are use by an out of proc service that imports files into the dataabse and does book keeping, and it has never hung. So maybe it's a bad interaction between our code and IIS. I wish we could proove it was a problem with our code -- at least then we could fix the bloody thing ;-)