[swift-evolution] [Discussion] Analysis of the design of typed throws

Anton Zhilin antonyzhilin at gmail.com
Thu Feb 23 12:30:09 CST 2017

2017-02-23 21:01 GMT+03:00 Matthew Johnson <matthew at anandabits.com>:
> I don’t understand what you mean here.

I was a bit confused. Thanks to your clarification, I discovered that
`rethrows` functions currently can use `throw` expression, but only in
`catch` scope, which handles error handling for one of function parameters.
In my view, this language feature should be removed without replacement if
we remove `rethrows`. Instead, we should always be able to throw error type
stated in `throws(...)`.

I don’t understand what you mean here.  In this alternative design *all*
> functions / closures / methods have an error type.  If one is not stated
> explicitly it defaults to `Never`.  If `throws` is specified without a type
> it defaults to `Error`.  There is no burden at all placed on callers.

I meant that in that specific case I would prefer returning an optional. If
error value is not meaningful--and that is the case with `f` function
parameter and corresponding `F` error type--then we are dealing with simple
domain errors, which are expressed with returning optionals instead of
throwing. I'll include this example anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170223/88041670/attachment.html>

More information about the swift-evolution mailing list