[swift-evolution] Throws? and throws!

[Xiaodi Wu]

On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> I really like swift’s error handling system overall. It strikes a good
> balance between safety and usability.
>
> There are some cases where it would be nice to throw errors, but errors
> are rarely expected in most use cases, so the overhead of ‘try’, etc… would
> make things unusable. Thus fatalError or optionals are used instead.  For
> example, operators like ‘+’ could never throw because adding ’try’
> everywhere would make arithmetic unbearable. But in a few cases it would
> make my algorithm much cleaner if I just assume it will work and then catch
> overflow/underflow errors if they happen, and resolve each of them with
> special cases.  Or perhaps I am dealing with user entered values, and want
> to stop the calculation and display a user visible error (e.g. a symbol in
> a spreadsheet cell) instead of crashing.
>

Unless I'm mistaken, there is a performance overhead for throwing
functions, and thus a much greater barrier to the use cases outlined above
is that the performance penalty for '+' would be unacceptable in any case,
whatever syntactic sugar you could come up with.


> I would like to propose adding ‘throws?’ and ‘throws!’ variants to
> ‘throws’.
>
> These would be used for cases where error handling is not the default
> desired behavior, but having it as an option is desired occasionally.


While I admit the idea has an appeal on a practical level, I have an
uncomfortable feeling about this. It's by definition true that error
handling is never the default desired behavior, and if I recall correctly
the performance of Swift error handling is tuned on the assumption that not
throwing is far more common than throwing. If we accept this statement at
face value as the justification for including `throws!`, then essentially
all `throws` should be `throws!`. And indeed I suspect that if the feature
were be implemented, that would rapidly become the case in much written
Swift. In essence, then, I think you're effectively proposing to invert the
assignment of responsibility for determining how errors are handled from
the call site to the declaration site, at least by default. It goes against
an overarching design principle in Swift (discussed earlier in the thread
about DefaultConstructible) not to provide such defaults and to require
explicitness at the call site.

Essentially, the user would no longer have to preface the call with ‘try’,
> as the compiler would implicitly add ‘try?’ or ‘try!’ respectively.
>
> Thus, the function would act like a non-throwing function (either trapping
> or returning an optional in the case of error), but the user could add
> ‘try’ to the call to override that behavior and deal with the error more
> explicitly.
>
> Another example would be bounds checking on arrays.  If subscripting
> arrays was marked as ‘throws!’ then it would have the same default behavior
> it does now (trapping on bounds error).  But a user could add ‘try?’ to
> return nil for a bounds error in cases where they explicitly want that, or
> they could add ‘try’ to deal with it as an error using do-catch.
>

Subscripts cannot throw at all at the moment, and in another thread some of
the challenges for designing throwing subscripts were just mentioned. I
suspect any sort of throwing subscript will not be possible in the
immediate future, so the argument for `throws!` here is moot.

I think this would really increase the availability of error handling in
> areas where it is impractical right now…
>

I think the practical argument could be made stronger by use cases not
encumbered by other difficulties as outlined above. Is there a currently
throwing function you've encountered that would be greatly improved by such
a feature? Besides that, though, my discomfort is (as mentioned above) that
the practical effect of such a feature is that it will actually altogether
invert the default responsibility for error handling, and I'm not sure that
it's entirely consistent with Swift's design as a consequence. In any case
it'd be a far greater change than you've made it out to be. Interesting
suggestion, definitely.

Thanks,
> Jon
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170112/1fb64757/attachment.html>