Having comprehensible error messages is related to being a simple language, IMO. C++ compile-time errors are notorious for being unreadable. I'm not familiar with the output of what(), but I'd wager that the problem is a consequence of all the abstraction.
stdio is program input, and a program's user should be informed about bad inputs. that said, usually, where hello world is usually demonstrated is far away from i/o so perhaps the negligence. but to argue that it's behaving correctly here is unnecessary.
I found it interesting. If you generalize a bit, the question is "Will a naively written stdio program handle IO errors?".
The fact that for several popular languages the answer is "no" is disappointing.
C and C++ distinguish between the language and its implementations (compiler plus runtime). Producing good error messages is the compiler's job, not the language's.
Yes, but in the cited example of basic_string, providing useful error messages isn’t actually that hard. It would be more interesting to hear an argument about what specific C++ features make providing useful error messages hard (if indeed they do) for which precise reasons, that would warrant the accusation that the language designers (rather than he compiler writers) didn’t pay attention to usability.
And of course C++ harks back to an era where error messages were not considered much of a concern. It took the Clang project for C compilation errors to start improving (including kicking gcc's ass), and C is not the most difficult language to parse/validate.
> implementations of stdio in libc generally do the right thing
Tell me, what is the "right thing" for stdio to do when it sees EINTR? It strikes me that this can't really be solved at the library level. There are times when you'll want to retry and there are times when you'll want to drop your work and surface the error to the caller. Doesn't seem to me like a library can decide which is which. Which is probably why the I/O syscalls need to surface it in the first place. (I'd argue if a library like stdio, which does nothing but wrap syscalls and buffer stuff, can decide it, then there's no need for EINTR to exist at all because the syscall could theoretically make the same decisions.)
When working with code with multiline macros, or complex templates, it is impossible to understand some errors. OP is gold right in that. C++ is so complicated, it is just impossible to make an efficient compiler that gives goos error messages.
Also having to ignore the pages after one error, to me, is a shittines indicator.
Favorite experience with compiler errors: C++ in 2004 or so, when the errors were so voluminous and inscrutable that you had to install another program to massage them into something readable.
I write compilers as a hobby. Providing good error messages is incredibly difficult—the compiler has a ton of information at hand, but it’s hard to know what’s actually useful to present, largely because you can only guess at the programmer’s actual intent.
I didn't use a lot of C or C++ but I agree from my limited experience. I noticed the warnings and errors kicked in when I did certain things. They aggravated or worried me. So, I figured out how to not cause them. Some of those became a habit even during my brief stints working in those languages. Same thing happens in other languages with good compilers.
Won't stop lazy people from ignoring them but that says more about them than the compiler. ;)
No it's human nature. Do people write code that will make error messages meaningful or not? That's something you see in type and variable names, filenames, warning hygenics, etc.
If the expected cost of decoding the error messages includes a lot of reverse engineering of crap code, people won't bother.
It was a major, major issue in early C++ template metaprogramming. You couldn't give good names to some of your constraints so the errors were nightmares.
It seems a little unfair to just jump to the conclusion that the problem is C, with basically no evidence of that. The multitude of "do" states did look confusing to me too, but without reading the code I can't say for sure that it's actually bad, and I definitely can not say why it became bad.
Having comprehensible error messages is related to being a simple language, IMO. C++ compile-time errors are notorious for being unreadable. I'm not familiar with the output of what(), but I'd wager that the problem is a consequence of all the abstraction.
reply