swift-argument-parser
swift-argument-parser copied to clipboard
Do not use throw on happy path
Currently, it seems that at ParsableArgumentsValidation.swift:140, there is a throw ValidationResult.success
that triggers on the regular happy path. This makes it very annoying to debug your code if you use a Swift error breakpoint in Xcode, as it will trigger several times before getting to the actual code that needs debugging.
I think most Swift code generally avoids throwing for program flow, and it would be nice if this code could also be changed to avoid that, to make debugging easier.
That throw is a part of command validation, and while I don't think there's a way to perform that particular kind of validation without throwing, it certainly doesn't need to run every time you debug your program. We could add a runtime flag that turns off command validation altogether, so you could debug your portion of the program without seeing that throw.
Why is the throw needed? It seems very un-Swift-like. Shouldn't the happy path of validation just run and return normally?
That validator in particular is verifying that each command's CodingKeys
type is set up correctly, but since that type is typically private and autogenerated, it's only available through a decoder. The validator uses a custom decoder to verify that the coding keys in the type match the properties that will need to be decoded. Since that custom decoder can't actually decode an instance without data to decode, it has to throw an error, even in the success state.
Does it need to be a separate pass? Could it be done during regular decoding instead?
This is a diagnostic, so it needs to be a separate pass. We want to run it on all the commands that are present, not just the one that’s decoded.
As a potential workaround, you mayb be able to set the Type
field in the breakpoint to the name of the error types you want to catch, though admittedly this isn't ideal if you have a bunch of error types or want to catch a ValidationResult
. (Command-Option-click on an error breakpoint to set the type.) There doesn't seem to be a way to negate the type, and I couldn't figure out what to use for a condition
.
Any progress on this? It's really annoying when you have a Swift-Error breakpoint set – or can we configure lldb to not break when in some packages?
A general purpose officially supported library that is intended to be included in every tool should not throw on the happy path. This should be hard requirement and this implementation should never have been released. If it is not possible for this implementation to not throw on the happy path, then it should be re-implemented.