> On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > >> On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull <[email protected] >> <mailto:[email protected]>> wrote: >> >> Also, ‘try’ is still required to explicitly mark a potential error >> propagation point, which is what it was designed to do. You don’t have >> ‘try’ with the variants because it is by default no longer a propagation >> point (unless you make it one explicitly with ’try’). > > If this is quite safe and more convenient, why then shouldn't it be the > behavior for `throws`? (That is, why not just allow people to call throwing > functions without `try` and crash if the error isn't caught? It'd be a purely > additive proposal that's backwards compatible for all currently compiling > code.)
Swift prefers that potential runtime crash points be visible in the code. You can ignore a thrown error and crash instead, but the code will say `try!`. You can force-unwrap an Optional and crash if it is nil, but the code will say `!`. Allowing `try` to be omitted would obscure those crash points from humans reading the code. It would no longer be possible to read call sites and be able to distinguish which ones might crash due to an uncaught error. (There are exceptions to this rule. Ordinary arithmetic and array access are checked at runtime, and the default syntax is one that may crash.) -- Greg Parker [email protected] <mailto:[email protected]> Runtime Wrangler
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
