use multiple exit codes to distinguish between errors & strict warnings

[jpsim]

Addresses #166.

Does this approach make sense to you all? /cc @jakecraige @kylef @scottrhoyt @norio-nomura

[jpsim]

Code	Meaning
0	No errors, maybe warnings in non-strict mode
1	Usage or system error
2	Style violations of severity "Error"
3	No style violations of severity "Error", but violations of severity "warning" with --strict

[scottrhoyt]

That's funny! I just implemented the same thing--though slightly differently. I created a new error type to be used as Commandant's ClientError

enum SwiftLintError: ErrorType {
    case ExitCode(Int)
}

LintCommand was similar to your implementation:

            if numberOfSeriousViolations > 0 {
                return .Failure(.CommandError(.ExitCode(2)))
            } else if options.strict && !violations.isEmpty {
                return .Failure(.CommandError(.ExitCode(3)))
            } 

Then in main.swift I modified the Commandant error handler to be:

registry.main(defaultVerb: LintCommand().verb) { error in
    queuedPrintError(String(error))
    switch error {
    case .CommandError(.ExitCode(let code)):
        exit(Int32(code))
    default:
        break
    }
}

The effect was the same as what you did, though I suppose it's a solution that might offer room for expansion to more types of errors/handling, but there's no good use case for that currently, so I'm happy to go with your much simpler approach. 👍

[jpsim]

Oh, sorry for stepping on your toes then @scottrhoyt! Your approach is definitely nicer, while mine is simpler. In this case, I'd prefer keeping things simple until that "doesn't scale" 😛

[scottrhoyt]

Premature optimization is the root of all evil. 😄

I'm all for simple. I'll keep it stashed away incase we go that direction.

[jpsim]

I'm all for simple. I'll keep it stashed away incase we go that direction.

👍

[jakecraige]

Awesome! Thanks for doing this.

[norio-nomura]

Nice!

[jinnatan]

Awesome