4 ms·

> That's a mischaracterization of most C code written by professionals I've been a professional programmer for 40 years, much of that in C. I've seen a lot of

by bregma 7y ago

> That's a mischaracterization of most C code written by professionals I've been a professional programmer for 40 years, much of that in C. I've seen a lot of code, some of it in production in critical systems for many years. It is not a mischaracterization, it is a description of the state of the art.

notacoward 7y ago
I'm sorry you've worked on so much crappy code. I have 30+ years' mostly-C experience myself, I've seen a lot of code that doesn't check or handle errors as well as it should, but code that routinely ignores errors (like e.g. most Python code) is a distinct minority. I wouldn't work on code that was "in production in critical systems" with that misfeature for very long before seeking a job where I could work with actual professionals.
- erik_seaberg 7y ago
  Python's default (stop and raise the exception in the caller) is almost always what you want. A stack of ten function calls should not have ten try blocks; that's a waste of effort and very hard to read.
  - notacoward 7y ago
    > Python's default (stop and raise the exception in the caller) No, Python's default behavior is an uncaught exception causing program termination with a stack trace, which is not generally what anyone wants. You have to add code to get non-default behavior. > A stack of ten function calls should not have ten try blocks While I agree with that, it's kind of missing the point. Exceptions can be used well. So can return codes. The problem is that when letting an error/exception be "someone else's problem" is the default, that tends to be what everyone does. It becomes nobody's problem, except the user who's left staring at an inscrutable program-termination message. It's the Volunteers' Dilemma in code. A good error-handling paradigm would require that errors be explicitly handled, passed on, or suppressed. Exceptions let them be invisible. C-style error returns are a bit cumbersome, but still better for correctness. My favorite approach right now is Zig's, based on error returns but with extra features (e.g. defer and try) to make common idioms less cumbersome. I've heard Rust is similar, but haven't really looked into it.

by bregma 7y ago

notacoward 7y ago

I'm sorry you've worked on so much crappy code. I have 30+ years' mostly-C experience myself, I've seen a lot of code that doesn't check or handle errors as well as it should, but code that routinely ignores errors (like e.g. most Python code) is a distinct minority. I wouldn't work on code that was "in production in critical systems" with that misfeature for very long before seeking a job where I could work with actual professionals.

erik_seaberg 7y ago
Python's default (stop and raise the exception in the caller) is almost always what you want. A stack of ten function calls should not have ten try blocks; that's a waste of effort and very hard to read.
- notacoward 7y ago
  > Python's default (stop and raise the exception in the caller) No, Python's default behavior is an uncaught exception causing program termination with a stack trace, which is not generally what anyone wants. You have to add code to get non-default behavior. > A stack of ten function calls should not have ten try blocks While I agree with that, it's kind of missing the point. Exceptions can be used well. So can return codes. The problem is that when letting an error/exception be "someone else's problem" is the default, that tends to be what everyone does. It becomes nobody's problem, except the user who's left staring at an inscrutable program-termination message. It's the Volunteers' Dilemma in code. A good error-handling paradigm would require that errors be explicitly handled, passed on, or suppressed. Exceptions let them be invisible. C-style error returns are a bit cumbersome, but still better for correctness. My favorite approach right now is Zig's, based on error returns but with extra features (e.g. defer and try) to make common idioms less cumbersome. I've heard Rust is similar, but haven't really looked into it.