> 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". -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
