cli: errors are displayed twice

[btc]

see ipfs2 add at fd9ffb5

[whyrusleeping]

@maybebtc which fish prompt/theme do you use?

[btc]

custom https://gist.github.com/maybebtc/3311c58cb4cf75e6b25c

[whyrusleeping]

Ah, nice! I approve! I just use a simple robbyrussel git info prompt.

[btc]

@mappum

In ipfs2 main, when the program decides what to write out to the user (based on result of command execution), what is the significance of commands.Response.Error.Code?

What I am reading is...

a) If the code is not ErrClient, return the error and only the error.

b) If the code is ErrClient, print help text.

However, having read through the source, I do not feel confident in my ability to predict how the framework will classify the wide range of errors into these two classes. Is there a principle behind the distinction?

The reason this is important is that the code appears to dictate the result displayed to the user:

This seems to be an ErrNormal:

go-ipfs (cmd-ref-part2) λ. ipfs2 diag net
ERROR: This command must be run in online mode. Try running 'ipfs daemon' first.

This is an ErrClient:

go-ipfs (cmd-ref-part2) λ. ipfs2 diag                                                                                
ERROR: This command can't be called directly. Try one of its subcommands.

USAGE:

    ipfs diag - Generates diagnostic reports

Use 'ipfs diag --help' for more information about this command.

@mappum can you help me understand?

[mappum]

@maybebtc The essential difference between the two is that ErrClient errors are a fault of the caller using the tool incorrectly (akin to HTTP 4xx errors), and ErrNormal is for any other errors (typically ones caused by the system, like HTTP 5xx).

For example, not providing a required argument would be an ErrClient, and would mean we should instruct the user on how to properly form a request (which is why we print the help text).

An error like timing out when trying to resolve an IPNS name would be an ErrNormal, as it's not a direct fault of the user, and help text wouldn't really be relevant to their problem.

[jbenet]

@mappum yeah there is a semantic distinction, but how are they distinguished in the code? who decides what the error is? Does each function -- on finding an error -- get to set wheter it's an ErrClient or ErrNormal? i think the main concern is about how obvious it is to a user.

[btc]

@jbenet thank you for getting to the kernel. How are they distinguished in code? What components are responsible for classification?

[jbenet]

I fixed this Issue. @maybebtc can you verify and close?