4 ms·

"As the author alludes to as well - in C you're made more aware of the error conditions you can handle and the ones you can't." You mean like when a function s

"As the author alludes to as well - in C you're made more aware of the error conditions you can handle and the ones you can't." You mean like when a function silently returns -1 to indicate failure and then you wonder why your program returned a wrong result (if you're lucky enough to even notice)? In the bigger part of most of my programs I want a big, flashy, loud, total failure by default if anything goes wrong.

amackera 18y ago
The only time a function would "silently" return a -1 would be if you're not checking your returns for errors! Functions have return codes for a reason.
- Hexstream 18y ago
  But oftentimes I want a correct result or an obvious failure, without having to handle tons of errors I don't even want to account for.
  - holygoat 18y ago
    Returning -1 is an obvious failure. What you're saying is that you want your programs to blow up when a function returns a known error (such as "disk full"). One of the points of the article is that C makes you think about all the possible, well-documented, errors that each function can encounter. You know when you write C precisely what can go wrong at each stage, and decide the right way to handle it. Seeing a dialog box pop up with some exception backtrace is one of the things that annoys me about 'modern' Java-esque languages: they seem to encourage developers to default to ignoring most exceptions.
    - aaronblohowiak 18y ago
      Defensive programming vs. `Let it fail`. I think the space between to two is more uncomfortable than either extreme.
    - wheels 18y ago
      Interestingly, I noticed earlier this week that the new GCC gives warnings when the return values of POSIX / libc functions are ignored but shouldn't be.
      - maw 18y ago
        Which versions of gcc and libc? Any special flags passed to gcc? I ask because I just tried it with a test program here (openSUSE Factory, gcc 4.3.3 and glibc 2.8.90) and it didn't print any warnings, but it would be nice if it did.
    - janm 18y ago
      The difference between letting an exception bubble up and seeing a system call fail and aborting is pretty small. Either way, you need a higher level way of dealing with it. One of the most interesting papers I read was "Why computers fail and what we can do about it" by Jim Gray while he was at Tandem. Transactions are essential, and most failures are transient. This can be applied at many levels, and can deal with many failures without the developer of the mainline code having to decide what to do for each given failure.
  - etal 18y ago
    Exactly. In properly written C, about half your code is checking for errors and handling them explicitly. If you don't do that, at some point it will blow your foot off; you have to account for those errors. C programmers have generally accepted this and thus spend an excessive amount of coding time thinking about and writing recovery mechanisms for external errors -- and that's why so many C programs are incredibly stable.
    - janm 18y ago
      Yes.
parenthesis 18y ago
if ((result = foo()) == -1) { fprintf(stderr, "!$*!$&^!$*!!!!\n"); exit(1); }
- Hexstream 18y ago
  That won't scale. I'm sure you'll have lots of fun grepping through your source files looking for "!$!$&^!$!!!!" when it appears on your stderr. The point is that with an exception system you don't have to write stupid shit like that everywhere just to crash and burn correctly. Failing loudly is the only sensible behavior when an unexpected error occurs and there's absolutely no indication of what to do in such a case.
  - mdakin 18y ago
    This is why assert exists. tyger(~)% cat << EOF > main.c ? #include <assert.h> ? ? void main( void ) ? { ? assert( 0 == 1 ) ; ? } ? EOF tyger(~)% gcc main.c main.c: In function ‘main’: main.c:4: warning: return type of ‘main’ is not ‘int’ tyger(~)% ./a.out Assertion failed: (0 == 1), function main, file main.c, line 5. Abort tyger(~)%
  - jodrellblank 18y ago
    From what breif comments I've read on Lisp's condition system, it sounds much better. Containing and isolating the error, as soon as possible, then passing information about the error higher up like an exception might propagate, until a level high enough to know the goal of the operation and what to do in case of errors, then passing a response back down, and being able to continue in a useful manner or tidy up gracefully. A great big codesplosion spraying you with a several hundred lines of stack trace and a "Your program has encountered an error an needs to close" is not "sensible behaviour".
    - Hexstream 18y ago
      "A great big codesplosion spraying you with a several hundred lines of stack trace and a "Your program has encountered an error an needs to close" is not "sensible behaviour"." Yes it is, if it's a program in development where I haven't yet decided what behavior an error condition should produce. You guys don't seem to understand I don't necessarily want to decide how to handle all errors now, not that I never want to have to think about how to handle them.
a-priori 18y ago
You mean like when a function silently returns -1 to indicate failure and then you wonder why your program returned a wrong result (if you're lucky enough to even notice)? This is the fault of the programmer who wrote the function, not of the language.
- Hexstream 18y ago
  What? What can a programmer do besides returning a "special" value such as -1 in a language like C with strict types and that doesn't support exceptions?
  - jwilliams 18y ago
    You don't need an exception mechanism to deal with this - good libraries will let you find out the exact condition (if you do get a -1 for example). By the same token, dozens of Java libraries only throw ABCException, with no other information... Might as well be -1.
    - wvenable 18y ago
      But you can't ignore the ABCException, your app will crash. If you ignore the -1, then you're app will happily continue on doing something wrong.
      - DarkShikari 18y ago
        Sure you can ignore it. You don't want to know the number of times I've seen people using the "try, catch, toss away the exception" structure in Java code.
        mstevens 18y ago
        But you have to actively decide to ignore it. Whereas when you're dealing with return codes, the default is to ignore.

amackera 18y ago

The only time a function would "silently" return a -1 would be if you're not checking your returns for errors! Functions have return codes for a reason.

Hexstream 18y ago
But oftentimes I want a correct result or an obvious failure, without having to handle tons of errors I don't even want to account for.
- holygoat 18y ago
  Returning -1 is an obvious failure. What you're saying is that you want your programs to blow up when a function returns a known error (such as "disk full"). One of the points of the article is that C makes you think about all the possible, well-documented, errors that each function can encounter. You know when you write C precisely what can go wrong at each stage, and decide the right way to handle it. Seeing a dialog box pop up with some exception backtrace is one of the things that annoys me about 'modern' Java-esque languages: they seem to encourage developers to default to ignoring most exceptions.
  - aaronblohowiak 18y ago
    Defensive programming vs. `Let it fail`. I think the space between to two is more uncomfortable than either extreme.
  - wheels 18y ago
    Interestingly, I noticed earlier this week that the new GCC gives warnings when the return values of POSIX / libc functions are ignored but shouldn't be.
    - maw 18y ago
      Which versions of gcc and libc? Any special flags passed to gcc? I ask because I just tried it with a test program here (openSUSE Factory, gcc 4.3.3 and glibc 2.8.90) and it didn't print any warnings, but it would be nice if it did.
  - janm 18y ago
    The difference between letting an exception bubble up and seeing a system call fail and aborting is pretty small. Either way, you need a higher level way of dealing with it. One of the most interesting papers I read was "Why computers fail and what we can do about it" by Jim Gray while he was at Tandem. Transactions are essential, and most failures are transient. This can be applied at many levels, and can deal with many failures without the developer of the mainline code having to decide what to do for each given failure.
- etal 18y ago
  Exactly. In properly written C, about half your code is checking for errors and handling them explicitly. If you don't do that, at some point it will blow your foot off; you have to account for those errors. C programmers have generally accepted this and thus spend an excessive amount of coding time thinking about and writing recovery mechanisms for external errors -- and that's why so many C programs are incredibly stable.
  - janm 18y ago
    Yes.

parenthesis 18y ago

if ((result = foo()) == -1) { fprintf(stderr, "!$*!$&^!$*!!!!\n"); exit(1); }

Hexstream 18y ago
That won't scale. I'm sure you'll have lots of fun grepping through your source files looking for "!$!$&^!$!!!!" when it appears on your stderr. The point is that with an exception system you don't have to write stupid shit like that everywhere just to crash and burn correctly. Failing loudly is the only sensible behavior when an unexpected error occurs and there's absolutely no indication of what to do in such a case.
- mdakin 18y ago
  This is why assert exists. tyger(~)% cat << EOF > main.c ? #include <assert.h> ? ? void main( void ) ? { ? assert( 0 == 1 ) ; ? } ? EOF tyger(~)% gcc main.c main.c: In function ‘main’: main.c:4: warning: return type of ‘main’ is not ‘int’ tyger(~)% ./a.out Assertion failed: (0 == 1), function main, file main.c, line 5. Abort tyger(~)%
- jodrellblank 18y ago
  From what breif comments I've read on Lisp's condition system, it sounds much better. Containing and isolating the error, as soon as possible, then passing information about the error higher up like an exception might propagate, until a level high enough to know the goal of the operation and what to do in case of errors, then passing a response back down, and being able to continue in a useful manner or tidy up gracefully. A great big codesplosion spraying you with a several hundred lines of stack trace and a "Your program has encountered an error an needs to close" is not "sensible behaviour".
  - Hexstream 18y ago
    "A great big codesplosion spraying you with a several hundred lines of stack trace and a "Your program has encountered an error an needs to close" is not "sensible behaviour"." Yes it is, if it's a program in development where I haven't yet decided what behavior an error condition should produce. You guys don't seem to understand I don't necessarily want to decide how to handle all errors now, not that I never want to have to think about how to handle them.

a-priori 18y ago

You mean like when a function silently returns -1 to indicate failure and then you wonder why your program returned a wrong result (if you're lucky enough to even notice)? This is the fault of the programmer who wrote the function, not of the language.

Hexstream 18y ago
What? What can a programmer do besides returning a "special" value such as -1 in a language like C with strict types and that doesn't support exceptions?
- jwilliams 18y ago
  You don't need an exception mechanism to deal with this - good libraries will let you find out the exact condition (if you do get a -1 for example). By the same token, dozens of Java libraries only throw ABCException, with no other information... Might as well be -1.
  - wvenable 18y ago
    But you can't ignore the ABCException, your app will crash. If you ignore the -1, then you're app will happily continue on doing something wrong.
    - DarkShikari 18y ago
      Sure you can ignore it. You don't want to know the number of times I've seen people using the "try, catch, toss away the exception" structure in Java code.
      - mstevens 18y ago
        But you have to actively decide to ignore it. Whereas when you're dealing with return codes, the default is to ignore.