[swift-evolution] Move placement of 'throws' statement

[Derrick Ho]

Right. it should support the normal return type as well as the errors. Here
is my revised suggestion.

func foo() throws -> String {}

switch try foo() {
case .returnValue(let value):
// do something with value

case .MyEnumErrorFirstError:
// handle error

default:
// handle NSError
}
On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I suppose "throws" could be enhanced to produce a compiletime enum
>
> func bar() throws {
> throw NSError()
> throw MyEnumError.firstError
> }
>
> Under the hood each expression passed to "throw" could make something like
>
> enum bar_abcdefj_throw {
> case genericError // all NSError go here
> case MyEnumErrorFirstError
> }
>
> Where abcdefj is unique characters.
>
>
> This enum would only be visible through the catch blocks which would act
> like a switch statement.
>
> Speaking of switch statements do they currently support "try" expressions?
>
> switch try foo() {
> case .MyEnumErrorFirstError:
> // handle error
> default:
> // handle NSError and everything else
> }
>
>
> If I'm not mistaken, `switch try foo()` switches over the return value of
> foo(); you'd switch over the error in a catch block.
>
>
> The benefit of this approach is that it would be additive. And no source
> breakage.
>
> At the risk of being off topic if there is interest in this I can start a
> new thread for this.
>
> On Tue, Dec 27, 2016 at 9:54 AM Haravikk <swift-evolution at haravikk.me>
> wrote:
>
> On 27 Dec 2016, at 13:43, Tino Heth <2th at gmx.de> wrote:
> Imho this is no problem:
> Right now, we basically have "throws Error", and no matter what is
> actually thrown, we can always catch exhaustive by keeping the statement
> unspecific.
>
>
> True, but for me it's more about knowing what a method can throw;
> currently to know that you need to consult documentation which, while fine,
> isn't the best way to do that when the compiler could know and it's then up
> to you whether to let it auto-complete for all throwable types, or just be
> generic for some or all of them (or pass the buck).
>
> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
>
> Imho to much confusion with no real benefit:
> Shouldn't it be up to the caller to decide which errors need special
> treatment? The library can't enforce proper handling at all.
>
>
> Partly, but it's really just intended to distinguish things that are
> genuine runtime errors, versus things that shouldn't have happened, i.e- an
> illegal argument type error shouldn't occur if you're using a method
> correctly, so it's more like something you might check as an assertion. I
> should have been more clear that the main difference is in how fix-its
> might recommend the errors are handled; specific types would produce catch
> blocks, but optionals might be grouped into a catch-all at the end (e.g-
> they're special interest that you might not be bothered about), but the
> compiler would still be aware of them should you decide to add them.
>
> If the distinctions not significant enough though then the "optional"
> error types could just be ignored for now, I think the more important
> ability is the ellipsis indicating "plus other errors" so we can specify
> either exhaustive lists of error types, or keep them open-ended, in which
> case the types listed are those that would be placed as catch blocks, with
> the ellipsis indicating that a catch-all is still required (or throw on the
> current method).
>
> One thing to note with explicit errors is that we'd basically introduce
> sum types…
>
>
> Not necessarily; you could think of explicit errors as being doing
> something like:
>
> enum MyErrorType {
> case io_error(IOError)
> case illegal_argument(IllegalArgumentError)
> case unknown(Error)
> }
>
> i.e- boilerplate we could do right now, but would prefer not to, but still
> allowing it to be handled as an enum.
>
>
> _______________________________________________
> 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/20161227/921ac978/attachment.html>