> On Sep 11, 2017, at 1:42 PM, Adam Kemp <adam.k...@apple.com> wrote: > >> Yes, this is a reasonable concern. We debated it heavily in the Swift 2 >> timeframe when introducing error handling (as other’s have pointed out, it >> works the same way). >> >> This is a tradeoff between the readability benefits of marking non-obvious >> control flow vs the readability disadvantage of having noise in the code. >> Requiring marking on every async or throwing call is particularly bad in the >> case of chaining. Compare: >> >> let x = try (try (try a.foo()).bar()).baz() >> vs: >> let x = try a.foo().bar().baz() >> >> In the Swift 2 timeframe, we decided that in many cases, it is mostly >> obvious what APIs can throw, so one marker is enough. That said, there ARE >> potentially confusing cases, and some programmers may want to be more >> explicit about marking. This is why the compiler allows you to explicitly >> mark subexpressions if you’d like. >> >> I believe that this design has served the community well, and I haven’t >> heard of serious problems with it. I’m pretty confident that async >> following the same model will have similar success. >> >> -Chris >> > > I think that decision makes sense for try/throws, but I feel like the await > keyword is fundamentally different from that. The pitfalls of not > understanding how the code is transformed and how it will behave at runtime > are much greater with await than with try. > > If you have a line of code with multiple expressions that can throw then the > consequences of not knowing which particular one threw the error are minor. > In most cases it doesn’t matter, and you would handle a given error the same > regardless of which subexpression threw the error. > > With await the function is actually broken up into pieces, and unrelated code > can run in between those pieces on the same thread and/or the same queue. > That has a much higher potential of leading to subtle bugs if you can’t see > where those breaks are.
What sort of bugs? Can you please provide a concrete example we can discuss? -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
