[swift-evolution] [Discussion] Analysis of the design of typed throws
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...
More information about the swift-evolution