<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-02-23 21:01 GMT+03:00 Matthew Johnson <span dir="ltr">&lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt;</span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>I don’t understand what you mean here.</div></div></div></blockquote><div><br></div><div>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.</div><div>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(...)`.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div></div></blockquote></div><br></div><div class="gmail_extra">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&#39;ll include this example anyway.</div></div>