Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 45

Thread: Why proper error handling should ALWAYS be done

  1. #21
    Join Date
    Dec 2006
    Location
    Australia
    Beans
    1,097
    Distro
    Xubuntu 15.10 Wily Werewolf

    Re: Why proper error handling should ALWAYS be done

    Quote Originally Posted by NathanB View Post
    There have recently been a number of convincing posts in these threads which demonstrate that this "exit()'s in shared libs" thing is a non-issue -- that it is simply your mis-understanding of how OOM issues are typically handled in Linux environments.
    To my knowledge, libraries should not cause ungraceful termination of applications.

    The reason why a lot of Linux libraries call exit() when OOM is imminent is not because that is best-practice. Rather, the reason is convenience, because Linux's OOM-killer will terminate a process with the highest memory consumption and lowest importance, as determined by it. So the rationale is "why bother"? The problem with this reasoning is that it promotes laziness.

    The OOM-killer is a last-resort defence against a system failure caused by lack of memory. Designing a shared library that relies on the OOM-killer to handle OOM situations is like removing airbags from a car because it already has seatbelts. In other words, while it saves development time and effort, it is unsafe and not best-practice.

    As we're all tech-savvy people, mostly with programming experience, some of us are professional programmers, what do we want to encourage in open source: reliable and safe software design and programming practices, or a "close enough is good enough" and "let's not do it because we can't be stuffed" approach to software?
    Last edited by samjh; November 19th, 2007 at 12:50 PM.

  2. #22
    Join Date
    May 2007
    Location
    Paris, France
    Beans
    927
    Distro
    Kubuntu 7.04 Feisty Fawn

    Re: Why proper error handling should ALWAYS be done

    Quote Originally Posted by samjh View Post
    what do we want to encourage in open source: reliable and safe software design and programming practices, or a "close enough is good enough" and "let's not do it because we can't be stuffed" approach to software?
    Reminds me of an old article I stumbled upon several times. Unfortunately I just can't find it again, so I'll try to resume it from what I remember.


    The article in question was about development methodologies of two different US universities participating to FOSS software (I'm pretty sure Berkeley is one of those two).

    One uni was all about "features are the priority" and "close enough is good enough" (as you put it). IOW, as soon as it is apparently stable, don't bother with it anymore and move on to something else. Surprisingly (to me, at least) features had priority over correctness and stability. At the time I thought this was just an heresy.

    The other uni (Berkeley IIRC) had the exact opposite stance. Correctness and stability were top priorities, features came last (and there were a few other criteria inbetween).


    Now, I'm not saying either POV is better than the other. Without innovation things can't get better, and without proven reliability things can only get worse, so we really need both.


    My current opinion is that Linux is more about innovation, and if you need unconditional reliability the BSD's are out there waiting for you.

    Don't get me wrong though, this doesn't mean that we shouldn't try to enhance both. But developing 100% reliable software is definitely a very slow process (and even BSD's are far from this), so it just can't follow the innovation's pace.
    Hopefully both can learn from each other though...

    My biggest rant being: why ignore existing rock-solid solutions in favour of less stable solutions, out of misplaced laziness(*)??


    PS: if anyone knows has a link to the article I'm referring to, I'd be glad to be able to bookmark it once for all. It's a quite short text but very informative.


    (*) We all know that a good programmer is a lazy programmer. But we better not forget that what you do now will save you tenfold work later, and what you avoid now will strike you back later... So doing it right *now* (including planning ahead) is my own personal definition of the True, Efficient Laziness (tm). And I defy anyone to be more lazy than me...
    Last edited by aks44; November 19th, 2007 at 09:28 PM.
    Not even tinfoil can save us now...

  3. #23
    Join Date
    May 2007
    Beans
    245
    Distro
    Ubuntu 10.04 Lucid Lynx

    Re: Why proper error handling should ALWAYS be done

    Quote Originally Posted by j_g View Post
    Um.... where??? I don't see any convincing posts detailing why there should be exit()'s in shared libs.

    All we know for sure is that malloc can indeed return a 0 on Linux (I've had it happen to me before), and if you fall into exit(), then you kill off the process. This is a nasty thing to do to an enduser (because it could result in him losing unsaved work, and is just plain annoying and unreassuring). It's also a nasty thing to do to an app programmer using your shared lib.
    Noone else wants to be nice enough to say this, so I will -- If you ever write a real world application which attempts to allocate enough memory to cause a 0 return value, then you should step-aside and let somebody more qualified write the program.

    In actuall practice, this "exit()" part of these library wrappers is just a comment -- it never gets executed. If it ever does, then your program has more serious issues to contend with {for instance... its author}.

  4. #24
    Join Date
    Oct 2006
    Location
    Austin, Texas
    Beans
    2,715

    Re: Why proper error handling should ALWAYS be done

    Quote Originally Posted by NathanB View Post
    In actuall practice, this "exit()" part of these library wrappers is just a comment -- it never gets executed. If it ever does, then your program has more serious issues to contend with {for instance... its author}.
    That makes it sounds a little more logical, but truthfully there isn't always a way to predict:

    a. How much memory the user of your library may need
    b. How much memory is available on your target system

    Because of this, it's just not friendly to expect that there will always be memory. One of my computers only has 256mb of ram, and the one I'm on right now only has 512... It's not hard to use all of that when you're running certain applications (especially sound or video related applications).

    Why is it too much to ask for the library writers to try to take care of this? Malloc usually returns NULL in those cases, and there's no reason a library shouldn't take that into consideration and try to gracefully pass it back to the library user so that they can say "well, my application is just a game, not need to worry, just exit" or "my application is handling potentially user-important data, I better report OOM to them so they can save their work".

  5. #25
    Join Date
    May 2007
    Location
    Paris, France
    Beans
    927
    Distro
    Kubuntu 7.04 Feisty Fawn

    Re: Why proper error handling should ALWAYS be done

    Quote Originally Posted by NathanB View Post
    If you ever write a real world application which attempts to allocate enough memory to cause a 0 return value, then you should step-aside and let somebody more qualified write the program.

    In actuall practice, this "exit()" part of these library wrappers is just a comment -- it never gets executed. If it ever does, then your program has more serious issues to contend with {for instance... its author}.
    In addition to Wybiral's post, I'll add that aggressive resource management is definitely a valid idiom (eg. on dedicated servers). FYI "scalable" is not a synonym of "conservative". A truly scalable program is able to use both hyper aggressive techniques as well as highly conservative ones, depending on its environment.

    The problem is that you can hardly guess when you'll "hit the wall", so by default you'll usually use aggressive methods until they fail (if they can fail gracefully...), then you'll scale down.


    Anyway...
    Quote Originally Posted by dwhitney67
    I'm a software engineer. For those of you who like to write poor code, please continue to do so. It will keep me employed until the day I retire.
    I could hardly agree more.
    Not even tinfoil can save us now...

  6. #26
    Join Date
    May 2007
    Beans
    245
    Distro
    Ubuntu 10.04 Lucid Lynx

    Arrow Re: Why proper error handling should ALWAYS be done

    Quote Originally Posted by Wybiral View Post
    That makes it sounds a little more logical, but truthfully there isn't always a way to predict:

    a. How much memory the user of your library may need
    This is easy to predict because you can simply decide not to support users of your library who are the type that foolishly and haphazardly abuse system resources.
    b. How much memory is available on your target system
    This is also easy to predict. Just slap a sticker on the box (or a note in the download product description) which informs the possible user what the system requirements are.
    Because of this, it's just not friendly to expect that there will always be memory. One of my computers only has 256mb of ram, and the one I'm on right now only has 512... It's not hard to use all of that when you're running certain applications (especially sound or video related applications).
    Congratulations!!! You have discovered what that "exit()" call is for!!

    Every Linux distro and most applications clearly indicate what they _require_ and _recommend_ in terms of system resources *before* you attempt to use that distro/app. As an application developer, you do not want to be in the position of providing technical support for a client who attempts to run your software on less than appropriate hardware. Do not do it. It is a waste of their time as well as yours. In the case that your application is ever put into *that* undesirable situation, you want your app to "exit()" immediately so that the user will clearly understand that it is not intended to function under those conditions.

    P.S. -- Suggestion to the Moderators: If you wish to reduce the occurance of these types of threads here, simply rename this subforum as "Programming Q&A" or similar. There exist plenty of newsgroups and language-specific forums around the 'net where these discussions can be argued to death... and they are probably a more appropriate venue. This forum's greatest asset is the answers that newcomers receive -- the rest, IMO, is immaterial.
    Last edited by NathanB; November 20th, 2007 at 12:29 AM.

  7. #27
    Join Date
    Apr 2006
    Beans
    10

    Re: Why proper error handling should ALWAYS be done

    Noone else wants to be nice enough to say this, so I will -- If you ever write a real world application which attempts to allocate enough memory to cause a 0 return value, then you should step-aside and let somebody more qualified write the program.
    As someone who actually writes "real world applications" where malloc() returning 0 is a very real possibility, I just want to be nice enough to tell you this: I'm sorry, but you don't know what you are talking about, and lennart of PA doesn't either. j_g is completely right in saying that a library should not look like this.

    What lennart is saying in his reply to the bug report is that since audio is of low priority, having the audio process die on a failed memory allocation is not a problem. The error he makes is thinking that the audio process is exactly that, a process that only plays audio. Since this function is exposed in the PulseAudio library however, that doesn't have to be the case. The process could be any program that uses PulseAudio. For example (not the best example, but anyway), if a program that as its main functionality keeps a respirator going, but uses PulseAudio to beep when human attention is needed, this program would crash on OOM. That would of course be unacceptable. Now, such a program would definitely not use PulseAudio, but to me it is not good library design to force applications to crash without a chance to die gracefully when it would be fully possible to let them.

    Yes, there are plenty of actual real world applications where this is an issue. Not many such applications are available for Linux. I wonder why? Unfortunately as long as the developers of core OS functionality refuse to even acknowledge that there are such applications, these applications are unlikely to ever be written for Linux.

    Now, this is not an attack on Linux, and other platforms have other issues. It's not even a gigantic issue (in this case). Just don't be fooled into thinking that because these particular programmers laugh at it, that it isn't real or isn't important. It is often more convenient to pretend an issue doesn't exist than it is to fix it, especially when you don't _have_ to fix it (as is often the case in free software).

    The plain truth is this: This is bad library design, and it is completely fixable. Is it worth fixing in this case? Maybe not. But it sure looks bad to a "real world programmer".

  8. #28
    Join Date
    Dec 2006
    Location
    Uk
    Beans
    109

    Re: Why proper error handling should ALWAYS be done

    Quote Originally Posted by Wybiral View Post
    Why is it too much to ask for the library writers to try to take care of this?
    Malloc succeeds when there may be no memory left when the process later uses the memory.
    The malloc/free paradigm is broken. Return values from malloc simply can not fix this problem. If the problem needs to be fixed then inside each library is not the place to do it.

    If you try to fix it in the libraries then.

    Each library needs it's own set of platform specific and possibly even kernel version specific code just to allocate memory. All this code needs to be maintained and bug fixed.

    The above point means most people can't write libraries without cargo culting memory allocation routines.

    All it takes is one process that doesn't do this to trigger the OOM killer which will potentially kill a "well behaved" process.

    That's why it is too much to ask for libraries to fix the problem. It's not their place to fix it and doing so has numerous downsides. Malloc was introduced precisely to remove these problems.
    Last edited by winch; November 20th, 2007 at 12:57 AM.
    OpenStreetMap - Free editable map of the whole world

  9. #29
    Join Date
    Sep 2005
    Location
    Cedar Rapids, IA, USA
    Beans
    545
    Distro
    Xubuntu 12.04 Precise Pangolin

    Re: Why proper error handling should ALWAYS be done

    Quote Originally Posted by NathanB View Post
    P.S. -- Suggestion to the Moderators: If you wish to reduce the occurance of these types of threads here, simply rename this subforum as "Programming Q&A" or similar. There exist plenty of newsgroups and language-specific forums around the 'net where these discussions can be argued to death... and they are probably a more appropriate venue. This forum's greatest asset is the answers that newcomers receive -- the rest, IMO, is immaterial.
    You haven't been around this forum for a while, some of us have gotten to be good friends and (I'm assuming here) are excited for a good discussion. This is also the most thoughtful discussion this group of people have had in a while on here, tis a shame mods have had to close threads.

    Since you're suggesting this why don't you go ahead and suggest a removal of the multiple "Which programming language" threads; those are far more annoying than this, and frankly **** me off because people don't know how to read the stickies.

    I like the fact that the OP is trying to raise awareness, however brash it is. Sometimes you have to break bridges to build new ones...
    Last edited by xtacocorex; November 20th, 2007 at 01:20 AM. Reason: that != than
    #399784 | Ubuntu User #287
    *** If you're going to program, install the damn build-essential package ***
    There is no such thing as Ubuntu specific programming
    Save the electrons - if you quote, trim!

  10. #30
    Join Date
    Oct 2006
    Location
    Austin, Texas
    Beans
    2,715

    Re: Why proper error handling should ALWAYS be done

    Quote Originally Posted by NathanB View Post
    This is easy to predict because you can simply decide not to support users of your library who are the type that foolishly and haphazardly abuse system resources.

    This is also easy to predict. Just slap a sticker on the box (or a note in the download product description) which informs the possible user what the system requirements are.

    Congratulations!!! You have discovered what that "exit()" call is for!!

    Every Linux distro and most applications clearly indicate what they _require_ and _recommend_ in terms of system resources *before* you attempt to use that distro/app. As an application developer, you do not want to be in the position of providing technical support for a client who attempts to run your software on less than appropriate hardware. Do not do it. It is a waste of their time as well as yours. In the case that your application is ever put into *that* undesirable situation, you want your app to "exit()" immediately so that the user will clearly understand that it is not intended to function under those conditions.

    P.S. -- Suggestion to the Moderators: If you wish to reduce the occurance of these types of threads here, simply rename this subforum as "Programming Q&A" or similar. There exist plenty of newsgroups and language-specific forums around the 'net where these discussions can be argued to death... and they are probably a more appropriate venue. This forum's greatest asset is the answers that newcomers receive -- the rest, IMO, is immaterial.
    I love how simple library / software design is for you. Your philosophy of "oh s**t, exit()" will probably lead you to writing tons of stable, scalable code. When in doubt, blame your laziness on your users... Yeah... That'll work. [/sarcasm]

    P.S. -- I don't think this forum is meant to be restricted to Q&A, it's a discussion forum. But if you want to tell the mods how to do their job, I'm sure they will appreciate it.

    P.P.S -- Occurrence is spelled with an "e"
    Last edited by Wybiral; November 20th, 2007 at 02:21 AM.

Page 3 of 5 FirstFirst 12345 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •