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
}
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-evolut...@haravikk.me>
wrote:
> On 27 Dec 2016, at 13:43, Tino Heth <2...@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
