>
>> There are large classes of programs where you can know you don’t care
>> exactly where a failure happens, e.g. (most init functions, all pure
>> functions, any function that doesn’t break invariants). In these cases
>> marking every statement or expression that can throw is just noise. Try
>> writing some serialization/deserialization code where the underlying stream
>> can fail to see what I mean; you’ll have “try” everwhere, and it adds
>> nothing to comprehensibility or maintainability. Personally I would like to
>> be able to label the function itself and not have to introuce a scope, but
>> IMO being able to create “try blocks” would be a welcome addition and would
>> even match the common case in blocks with catch clauses, where being aware
>> of the exact line where the error was generated is typically not useful.
>
> That's a really interesting idea, but I don't think it's what the poster was
> suggesting. It sounded to me like he was merely saying “let's make the Swift
> error system look like my favorite language's exception system".
I agree with Brent’s assessment of the OP. However that doesn’t mean that Dave
does not have a good point. Here is some code from a recursive descent parser.
(More correctly: the recognizer. Omitting the AST-building stuff.)
func recognizeHandler() throws {
try accept(.on) // .on is an enum tag for the token for the ‘on’
keyword.
try recognizeName()
try recognizeFormalParamSeq()
try accept(.newline)
try recognizeCommandSeq()
try accept(.end)
try recognizeName() // Later Visitor pass checks that names match.
try accept(.newline)
}
There is a lot more where that came from.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
