Remove side-effects in HelpCommand

[miguelangel-dev]

Currently HelpCommand is launching a side-effect in run method (printing in the console the help). This PR fixes it and throw the effect to the next layer, who will catch it and treat the effect properly. Effects should be handled on the main method inside exit(withError:) or let to the user decided how to manage them

This change will let us write something like:

enum ParsableCommandError: Error {
    case general(String)
}

extension ParsableCommand {
    func parse(_ arguments: [String]? = nil) -> Result<ParsableCommand, ParsableCommandError> {
        do {
            let command = try Self.parseAsRoot(arguments)
            try command.run()
            return .success(command)
        } catch {
            let info = Self.fullMessage(for: error)
            return .failure(.general(info))
        }
    }
}

In the end, delegate the responsibility about when executing the effects and how handling

I have tested it using ParsableCommand with subcommands and without them. It works properly in both cases.

Checklist

• I've added at least one test that validates that my change is working, if appropriate
• I've followed the code style of the rest of the project
• I've read the Contribution Guidelines
• I've updated the documentation if necessary

[miguelangel-dev]

@natecook1000 please, we are working on a migration in our lib nef and we need this change. Could you review it? Thanks

[natecook1000]

Thanks @miguelangel-dev — I'm going to merge this change. The thing we're missing for full manual handling of errors is a way to determine whether an error is really an "error", since you'd want to treat a validation error separately from a help request. I'll fill that hole in a follow-up PR before version 0.0.3.

[natecook1000]

See #79 for the WIP new method — any feedback you have would be great!

[miguelangel-dev]

I'm going to merge this change. The thing we're missing for full manual handling of errors is a way to determine whether an error is really an "error", since you'd want to treat a validation error separately from a help request. I'll fill that hole in a follow-up PR before version 0.0.3.

It sounds good. Thanks for the info, I will keep an eye in the #79