8 ms·

If stdout fails and your program's purpose is to print to stdout, for example, if you are `cat`, `less`, `diff`, `ps`, `ls`, etc... then you should print an err

If stdout fails and your program's purpose is to print to stdout, for example, if you are `cat`, `less`, `diff`, `ps`, `ls`, etc... then you should print an error message to stderr and exit with an error code. The super common use case is std.debug.warn, not printing to stdout.

int_19h 8y ago
I think it might be helpful if the name of warn() did not imply that the message is actually a warning, i.e. that "something bad happened". There are many legitimate cases for printing purely informational messages to stderr - operation progress, that sort of thing. When someone sees a hello world app in Zig, and there's warn() in it, the first knee-jerk reaction is, "so what are we warning about?". I would actually even argue that the meaning of "print" as printing to stdout by default is an unfortunate historical artifact. For the kind of stuff print is usually used by most of the code, it really should go to stderr, and "print" kinda implies some kind of logging IMO. From that perspective, my suggestion would be to add a no-failure @import("std").debug.print that is an alias for warn. I don't think it's likely that breaking the established convention of print-defaults-to-stdout would cause issues in practice - in programs where this matter (like cat), the developer will quickly discover the issue the moment they try using it in a pipeline. And for programs where it doesn't, defaulting to stderr is actually the right thing. But if you'd rather not break the convention, how about adding debug.log that is an alias for debug.warn? Or debug.say, or something like it.
- v_lisivka 8y ago
  Standard output for errors is for errors only, or for debugging information if enabled manually. Please, don't abuse stderr, because admins are very dependent on it to be clean. Use stderr for errors and stdout for anything else. If you need your own output stream with your own output rules, just print to file.

int_19h 8y ago

I think it might be helpful if the name of warn() did not imply that the message is actually a warning, i.e. that "something bad happened". There are many legitimate cases for printing purely informational messages to stderr - operation progress, that sort of thing. When someone sees a hello world app in Zig, and there's warn() in it, the first knee-jerk reaction is, "so what are we warning about?". I would actually even argue that the meaning of "print" as printing to stdout by default is an unfortunate historical artifact. For the kind of stuff print is usually used by most of the code, it really should go to stderr, and "print" kinda implies some kind of logging IMO. From that perspective, my suggestion would be to add a no-failure @import("std").debug.print that is an alias for warn. I don't think it's likely that breaking the established convention of print-defaults-to-stdout would cause issues in practice - in programs where this matter (like cat), the developer will quickly discover the issue the moment they try using it in a pipeline. And for programs where it doesn't, defaulting to stderr is actually the right thing. But if you'd rather not break the convention, how about adding debug.log that is an alias for debug.warn? Or debug.say, or something like it.

v_lisivka 8y ago
Standard output for errors is for errors only, or for debugging information if enabled manually. Please, don't abuse stderr, because admins are very dependent on it to be clean. Use stderr for errors and stdout for anything else. If you need your own output stream with your own output rules, just print to file.