4 ms·

A few things to unpack here. First, this is just an example. A real world scenario would be something domain specific. Maybe I could come up with a better contr

A few things to unpack here. First, this is just an example. A real world scenario would be something domain specific. Maybe I could come up with a better contrived example here. Still, conceivably the app could check the file owner before showing the message. If it was a common enough error, it might be useful to do something like this. There is a difference between an error title and error description. The description can and should be long to help clarify what is wrong. It's ok to be verbose. It's ok to spill out on multiple lines. You're much more likely to be helpful to a confused user than someone grepping logs and looking for terse output on a single line. That user can just use `grep -C` anyways. I agree that it's useful to include the app name though.

dkersten 8y ago
Its easier to google a terse one-line error than a multi line error.
- dickeytk 8y ago
  That's what the error code is for
  - voltagex_ 8y ago
    iPXE is the best example I've seen of that - every error code is a link to a wiki.
  - IcePic 8y ago
    IBM does that, some ANS4543 code that is the real error, _then_ a possibly translated-to-your-language error sentence that tries to help you, but if it isn't enough, you google for the error code and can potentially find help regardless of what language the blog post is in, or the forum link or whatever.
    - JdeBP 8y ago
      Indeed, on OS/2 one didn't google for the error code. One used the HELP command, one of whose modes of operation was looking up and printing the short and long message texts for such codes. The latter would often contain both EXPLANATION and ACTION parts. [C:\]help sys0003 SYS0003: The system cannot find the path specified. EXPLANATION: The path named in the command does not exist for the drive specified or the path was entered incorrectly. [C:\]help sys0002 SYS0002: The system cannot find the file specified. Explanation: The filename is incorrect or does not exist. Action: Check the filename and retry the command.
cyphar 8y ago
The example provides the same error information three times ("EPERM", "Invalid permissions on myfile.out", "Cannot write to myfile.out, file does not have write permissions"), followed by a recommendation that might not be correct. Yes, this is an example, but surely you'd want an example that shows the strength of doing this verbosely? A good example of a verbose error message system is Rust's compiler output (or newer clang/gcc outputs). Being verbose for no reason other than to be verbose is just wasting the users' time (or they just ignore the spam -- which is what I would do if I used a tool that spammed me with multiple lines of output whenever it hit an -EPERM). Personally, something like: % foo ./bar foo: write config to "./bar": Permission denied Is clearer to me than your example. Maybe something like % foo ./bar foo: write config to "./bar": Permission denied Hint: Have you tried <possible-recommendation>? Is sometimes okay (and I have done this for my own projects as well), but it's something that should be done in moderation... > You're much more likely to be helpful to a confused user than someone grepping logs and looking for terse output on a single line. There are two sides to this. Outputting lots of text can also cause a user to get confused (if we're talking about making things easy for not-necessarily-technical users). When teaching (high-school) students to program, we quickly learned that even somewhat verbose output like Python's stacktraces can cause students to suddenly become anxious because there's a pile of text on their screen telling them they did something wrong. Adding more text to output does not always help, and you should keep that in mind.

dkersten 8y ago

Its easier to google a terse one-line error than a multi line error.

dickeytk 8y ago
That's what the error code is for
- voltagex_ 8y ago
  iPXE is the best example I've seen of that - every error code is a link to a wiki.
- IcePic 8y ago
  IBM does that, some ANS4543 code that is the real error, _then_ a possibly translated-to-your-language error sentence that tries to help you, but if it isn't enough, you google for the error code and can potentially find help regardless of what language the blog post is in, or the forum link or whatever.
  - JdeBP 8y ago
    Indeed, on OS/2 one didn't google for the error code. One used the HELP command, one of whose modes of operation was looking up and printing the short and long message texts for such codes. The latter would often contain both EXPLANATION and ACTION parts. [C:\]help sys0003 SYS0003: The system cannot find the path specified. EXPLANATION: The path named in the command does not exist for the drive specified or the path was entered incorrectly. [C:\]help sys0002 SYS0002: The system cannot find the file specified. Explanation: The filename is incorrect or does not exist. Action: Check the filename and retry the command.

cyphar 8y ago

The example provides the same error information three times ("EPERM", "Invalid permissions on myfile.out", "Cannot write to myfile.out, file does not have write permissions"), followed by a recommendation that might not be correct. Yes, this is an example, but surely you'd want an example that shows the strength of doing this verbosely? A good example of a verbose error message system is Rust's compiler output (or newer clang/gcc outputs). Being verbose for no reason other than to be verbose is just wasting the users' time (or they just ignore the spam -- which is what I would do if I used a tool that spammed me with multiple lines of output whenever it hit an -EPERM). Personally, something like: % foo ./bar foo: write config to "./bar": Permission denied Is clearer to me than your example. Maybe something like % foo ./bar foo: write config to "./bar": Permission denied Hint: Have you tried <possible-recommendation>? Is sometimes okay (and I have done this for my own projects as well), but it's something that should be done in moderation... > You're much more likely to be helpful to a confused user than someone grepping logs and looking for terse output on a single line. There are two sides to this. Outputting lots of text can also cause a user to get confused (if we're talking about making things easy for not-necessarily-technical users). When teaching (high-school) students to program, we quickly learned that even somewhat verbose output like Python's stacktraces can cause students to suddenly become anxious because there's a pile of text on their screen telling them they did something wrong. Adding more text to output does not always help, and you should keep that in mind.