Harmonize BeforeError handling

[creekorful]

What type of PR is this?

• bug
• cleanup
• documentation
• feature

What this PR does / why we need it:

The error handling using BeforeFunc is now harmonized between App#RunContext, App#RunAsSubcommand & Command#Run.

Which issue(s) this PR fixes:

Fixes #1081

Release Notes

(REQUIRED)

Error handling using BeforeFunc is now harmonized between App#RunContext, App#RunAsSubcommand and Command#Run.

[rliebz]

Thanks for following up! This is great.

I did a quick audit of the code base, it looks like there's one more BeforeFunc that prints command help in case of errors:

cli/command.go

Lines 150 to 157 in 4bb97e0

	if c.Before != nil {
	err = c.Before(context)
	if err != nil {
	_ = ShowCommandHelp(context, c.Name)
	context.App.handleExitCoder(context, err)
	return err
	}
	}

Would you mind dropping the call to ShowCommandHelp there as well for consistency?

[creekorful]

Thanks for following up! This is great.

I did a quick audit of the code base, it looks like there's one more BeforeFunc that prints command help in case of errors:

cli/command.go

Lines 150 to 157 in 4bb97e0

	if c.Before != nil {
	err = c.Before(context)
	if err != nil {
	_ = ShowCommandHelp(context, c.Name)
	context.App.handleExitCoder(context, err)
	return err
	}
	}

Would you mind dropping the call to ShowCommandHelp there as well for consistency?

Yup, my bad should have seen this one.

Done !

[creekorful]

Btw is it wanted that this logic is uncoupled and not centralised?

IMHO since the BeforeError handling is common (and this is wanted) between the 3 occurrences, I would have centralise the logic somewhere

[rliebz]

There's a lot of logic like this that I'd like to see centralized. There are subtle reasons why it's not that way right now, such as repeated logic for different types or handling named return parameters. Not that it can't be improved—it absolutely can be. But it's not necessarily easy.