>>
>> func recognizeHandler() throws {
>> try {
>> accept(.on) // .on is an enum tag for the token for the ‘on’
>> keyword.
>> recognizeName()
>> recognizeFormalParamSeq()
>> accept(.newline)
>> recognizeCommandSeq()
>> accept(.end)
>> recognizeName() // Later Visitor pass checks that names match.
>> accept(.newline)
>> }
>> }
>
>
> Indeed. Also, FWIW, I’d argue that maybe the root problem here is that this
> code should not be using Swift’s error handling constructs in the first
> place. An enum (or other approach) may be more appropriate. Swift’s error
> handling design is intentionally driven by the idea that you shouldn’t use it
> if “everything throws” - in this situation, the sugar benefits of error
> handling are intentionally outweighed by the weight of the try keywords
> everywhere. This is meant to force the balance over to using more manual
> techniques.
>
> -Chris
Quite so. That is what prompted an earlier suggestion/request about guarding on
Optionals:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004217.html
In fact, I did go with a construct like
let r = returnsSucceedOrFailOptional()
guard case let .Succeed(node) = r else { return r } // Back down the call
stack.
// Safe to use node; r now irrelevant but in scope.
and put up with the fact that the unwanted r was still in scope. Alas, my LOC
soared. More code, more bugs.
Apart from considerations of propriety, are there performance up/downsides to
either approach?
- AMD
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
