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

Xiaodi Wu xiaodi.wu at gmail.com
Tue Dec 27 15:17:18 CST 2016

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>

More information about the swift-evolution mailing list