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

6 of 610 comments (clear)

  1. fp by titurel · · Score: 0, Troll

    pirst prost

  2. agreed by vcv · · Score: 0, Troll

    agreed, bad error handling.

  3. That all depends on your point of view by CmdrTroll · · Score: 1, Troll
    Most open source software is not designed to be used by the average, clueless user. It is designed to be used by experienced power users, who know the difference between right and wrong and don't do stupid things to upset the machine. Furthermore, Linux supplies many powerful diagnostic tools (gdb, strace, ltrace, dmesg, etc.) which would cost hundreds or thousands of dollars on other platforms (that means you too, Sun). Those tools are there for a reason: if you have an application failure, you will be able to figure out what caused it very quickly - IF you know what you're doing.

    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

    1. Re:That all depends on your point of view by anti-drew · · Score: 0, Troll

      That's a lame excuse if I ever heard one.

      Human fallibility (operator error to you) is the norm, not the exception. And error handling applies to bugs as well as human error. And, even in Linux, you can't expect even an expert hacker to be an expert on EVERY piece of software on their computer. Nuclear physicists writing sophisticated entropy generators for /dev/random may not know enough to figure out what's gone wrong with their DHCP configuration under PPPoE.

      Even if the odds of a particular bug or error occurring are 10 million to 1, run the code frequently enough and someone is going to hit it. Trained engineers are aware of this. Hobbyists and part-time hackers often aren't.

      Nor is flexibility and functionality at odds with good error handling. Take a design class sometime!! Sheesh!

      -d

  4. Three true things by WillSeattle · · Score: 0, Troll

    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?
  5. I got your fix RIGHT HERE! by Dast · · Score: 2, Troll

    I'll be blunt. Open source programmers need to stop being so darned lazy about e rror handling. That obviously doesn't include all open source programmers. You k now who you are.

    If you want a demonstration of what I mean, start your favorite GUI-based open s ource applications from the command line of an X terminal instead of a menu or i con. 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 exce ptions, 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 war nings or error messages to a few hundred. And I'm not just talking about the deb ug messages that programmers use to track what a program is doing. I mean warnin g messages about missing files, missing objects, null pointers, and worse.

    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.