I’m having a hard time seeing what is wrong with println actually checking for errors, unlike C in practice.https://twitter.com/myrrlyn/status/1170035475593064448 …
-
-
Replying to @pcwalton
In C it does, right? Just everybody ignores the return value of printf because there’s no reasonable recovery action.
1 reply 0 retweets 2 likes -
Sure there is, but the reasonable action depends on the program. Not on the stdlib deciding "oh, you should abort". Also, in C ignoring the return value of printf DOES NOT imply ignoring the error, since stdio errors are sticky. ferror(stdout) lets you see it later.
3 replies 1 retweet 10 likes -
Replying to @RichFelker @pcwalton
Totally agree, but I’ve yet to encounter a program that had a reasonable workaround to stdout writes failing. And you’re right that panic on this error in a library is just plain broken.
1 reply 0 retweets 1 like -
Every single C implementation of the standard posix utilities gets this right. Easiest way is just doing fflush and ferror before exiting, returning failure exit status if true. No need to check every call. gnulib automatically does it in gnu software.
1 reply 0 retweets 3 likes -
Replying to @RichFelker @pcwalton
Is non-zero exit for a printf failure appropriate? If a program is using stdout for status updates while it does some other op, maybe it completed its task successfully.
1 reply 0 retweets 0 likes -
For the std utilities, yes. In general, it depends on the program. This is why println panicing is such a bad design. If stdout is just informative and success/failure of the writes there have nothing to do with success/failure of the command, failure should be ignored.
2 replies 0 retweets 4 likes -
Replying to @RichFelker
I think I recall someone bringing this up at the time, but people were generally uncomfortable with ignoring errors without explicit intent by the programmer, as a general principle. Maybe that was the wrong decision, but the library was designed conservatively.
1 reply 0 retweets 0 likes -
Replying to @pcwalton
I think "ignoring an error that's a valid condition runtime condition, not a programming error" is a much more conservative behavior than "aborting the program". But making intent explicit is better than either.
2 replies 0 retweets 4 likes
I found some related issues. This was discussed in 2014: https://github.com/rust-lang/rust/issues/13824 … And again in 2015: https://github.com/rust-lang/rust/issues/24821 … So yeah, that was the reasoning. I don’t really have much of an opinion as I can see both sides. Like I said I wouldn’t object to deprecating println.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.