The unknown commnd error should be easily recognizable

[JAicewizard]

Currently an unknown command error is indistinguishable from any other error from within cobra, so it is hard to differentiate between actual errors, and the user mistyping something.

[wfernandes]

@JAicewizard Could you provide some more details on what errors seem indistinguishable?

Is this something that suggestions could help with?
https://github.com/spf13/cobra#suggestions-when-unknown-command-happens

[JAicewizard]

when running rootCmd.Execute() it returns an error when it encounters an unknown command, even though the error is already handled gracefully within cobra itself.
In my program I panic when I encounter an error from cobra, which is sensible since there is no graceful way to handle errors in starting my application.
But there is no way to differentiate between errors that are already gracefully handled and I shouldn't care about, like unknown command, and ones that are not already handled and I should panic for.
To me it seams non-logical to return already handled errors anyway, everything went as planned and the user mistake has already been handled properly, no need to pass it up t be handled there too.

[jharshman]

@JAicewizard, it seems pretty common to me to return an error in the case of an unknown command. Much like many other CLIs, when they are misused, an error and usage message is returned to the caller.

Are you returning errors to the caller with RunE ?

[JAicewizard]

@jharshman I dont use RunE, and usually in go once the error has been handled properly it doesn't get propagated up. The rootCmd.Execute() ran succesfullly, it didnt encounter any unrecoverable errors. It did encounter a problem but it has already been handled, and thus the caller doesnt have to take care of it anymore. Returning an err implies that the caller has to deal with it because it hasnt been dealth with yet.

[jharshman]

@JAicewizard , I understand where you're coming from. However, in this case, the correct response to an unknown command error is to return it to the user. This is common behavior among other CLI utilities.

[github-actions]

This issue is being marked as stale due to a long period of inactivity

[wfernandes]

I think we can close this issue if this is not intended behavior. WDYT? @jharshman

[jharshman]

Agreed, focus should instead be on consistent error propagation as is being discussed in #1156.