[swift-evolution] Throws? and throws!

Xiaodi Wu xiaodi.wu at gmail.com
Thu Jan 12 19:39:14 CST 2017

On Thu, Jan 12, 2017 at 7:34 PM, Greg Parker <gparker at apple.com> wrote:

> On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
> On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull <jhull at gbis.com> 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.)

FWIW, that was meant to be an argument a fortiori (well, ad absurdum, I
suppose). If `throws!` is a good idea (whose purpose is to permit omission
of `try!` at call sites), then how much nicer would it be if we could just
do that with `throws`. It is, after all, technically source compatible. But
it is not, I agree, such a good idea with `throws`, so I'm skeptical of its
worth with the increased burden of new syntax.

> Greg Parker     gparker at apple.com     Runtime Wrangler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170112/edf9e638/attachment.html>

More information about the swift-evolution mailing list