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

Tue Dec 27 15:58:37 CST 2016

Agree, it doesn't seem to read naturally at first glance.

However, one way perhaps to think about the rationale for this is that
`throws` does "fit" logically between the parameters and the return type: a
function that throws might take certain arguments and, by throwing, never
return a value of the stated return type. In that perspective, `throws`
could be justified in its current position interposed between the input and
the desired output.

On Tue, Dec 27, 2016 at 4:51 PM, thislooksfun via swift-evolution <
swift-evolution at swift.org> wrote:

> If some form of explicitly typed errors is added, my initial problem goes
> away. The only reason I suggested the move in the first place, is that a
> combination of `throws` and return (-> T) statements makes it *look* like
> there is already explicitly typed errors, especially to those of us coming
> from Java.
>
> -thislooksfun (tlf)
>
> On Dec 27, 2016, at 3:41 PM, Karl via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Moving “throws” or changing it to a prefix “throwing” as was originally
> suggested are relatively minor, reasonable improvements.
>
> We do need to consider if it restricts future language evolution (such as
> potentially listing all of the thrown errors), so that’s why it’s relevant
> to talk a little bit about that and what are options would be; but I think
> fundamental, non-backwards compatible changes to how you invoke throwing
> functions are probably too big to be reasonable.
>
>
I'm -1 on big changes such as suggested as well. The deliberate choice to
separate error handling from other code with `do { }` was a deliberate
design choice and it'd be very disruptive to break that now. And in terms
of just gut feeling, switching over errors and return values at the same
time seems like going in the wrong direction.

> - Karl
>
> On 27 Dec 2016, at 22:31, Derrick Ho <wh1pch81n at gmail.com> wrote:
>
> 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
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> 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/bc1ffc3e/attachment.html>