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

[Xiaodi Wu]

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/6b0a47cd/attachment.html>