Requesting suggestions for error messages

[GrayJack]

I personally I'm not satisfied by the state of the error messages in the tools right now and since the POSIX standard doesn't specify how error messages should be, we are free to change and improve anything we don't like.

From the top of my head, although not a complete list, these are the things that I'm not satisfied:

• The error messages shown by clap and by the tool itself doesn't use the same formatting
• Errors messages thrown by the tool is colorless (In this regard I like clippy error messages more)
• Errors messages thrown by clap doesn't start with the name of the tool

So... What do you dislike about the error messages of the tools? Any suggestion or ideas to improve the errors?

[marcospb19]

Hey @GrayJack

Errors messages thrown by clap doesn't start with the name of the tool

I agree with this, we can fix it by using clap::App.get_matches_safe().

Errors messages thrown by the tool is colorless (In this regard I like clippy error messages more)

I would love to have some examples of some utils playing with colors for us to debate.

The error messages shown by clap and by the tool itself doesn't use the same formatting

I don't think we can achieve this consistency, because clap error messages are long with multiple blocks: the error, the suggestion (when possible), the usage, and "For more information try --help".

And the messages from the coreutils are usually shorter

head: Cannot open 'file_name' for reading: No such file or directory (os error 2)

Personally, this doesn't bother me, I see it as two different layers of error messages, wrong usage error (like a compile error) and runtime error.

That being said, do you expect to change the CLI lib for the project in the future?

[GrayJack]

I don't think we can achieve this consistency, because clap error messages are long with multiple blocks: the error, the suggestion (when possible), the usage, and "For more information try --help".

Same formatting would be something like all messages like <bin>: error: [msg]:+. Suggestion and usage and "For more information try --help" should be used when needed

And the messages from the coreutils are usually shorter

And it should be when all information is given, but as example, seq (I picked this one since it was the last tool I was looking at the code yesterday) when you pass too many arguments it's just says seq: extra operand '{}'\n Try 'seq --help' for more information. when it is possible to say more about it, also there is a inconsistency of the error messages when used without operands and with extra operands (kinda "fixed" by last commit, now both errors are reported by clap). Also the clap default report I feel it isn't as good as it could be for seq since seq only has a max of 3 operands and a min of one.

That being said, do you expect to change the CLI lib for the project in the future?

Change the lib, no, but I want to upgrade to clap 3.0

[EduRenesto]

Yoo!

From what we have talked, I'd first suggest using the log facade together with a custom logger implementation. This way we can get a custom, uniform error message format throughout the project, and leverage the whole macro collection (info!, error!() and friends) from the log crate. This would be at least good for the runtime errors that @marcospb19 said. However, this feels a bit too ad hoc to me, since one would need to actually call the reporting macros in the event of an error.

The better solution IMO would be using something like eyre, together a custom report handler. This way we can get sweet idiomatic error handling in the code just by using the familiar Result<T, E> enum and all its goodies, without having to actively scream out the error whenever it happens. And still we'll have an uniform error message format for all the tools throughout the project.