Right now, it's because throws does not specify a type to be thrown, and the compiler doesn't know that you've checked all the possibilities. For all it knows, it could be something else than a MyError.
> Le 18 déc. 2015 à 21:28:41, Ricardo Parada via swift-evolution > <[email protected]> a écrit : > > Thanks for the clarification. Why is the compiler saying that the catch is > not exhaustive when it is covering all the possible values of the enum? Is > it to be able to catch future values added to the enum type? > > >> On Dec 18, 2015, at 8:05 PM, David Owens II <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On Dec 18, 2015, at 4:38 PM, Ricardo Parada <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi David >>> >>> I started reading your proposal and I have a couple of questions. >>> >>> In the Enum Base ErrorType example you mentioned that it requires a "catch >>> { }" clause. However the code is already covering the two possible Enum >>> values (OffBy1 and MutatedValue). Why is the "catch { }" required? I typed >>> that code into a playground and I did not get any errors. Are you saying >>> that because the Enum type could add a value in the future? >> >> Playgrounds are basically in an anonymous function that throws, so the >> problem doesn’t show up there at the top level. Copy this into your >> playground. >> >> enum MyError: ErrorType { >> case OnlyOne >> } >> >> func thrower() throws { throw MyError.OnlyOne } >> >> func nolies() { >> do { >> try thrower() >> } >> catch MyError.OnlyOne { print("handled") } >> // catch { print("compiler error until uncommented") } >> } >> >>> Also, you proposed the catch clause to use error as the name of the >>> constant holding the error. Wouldn't it be better to let the programmer >>> decide the name rather than hard coding it to use error? For example: >>> >>> catch e where e.value == 0 { print("0") } >>> catch e where e.value == 1 { print("1") } >>> catch { print("nothing") } >> >> The “error” name is already specified in the Swift rules for what the >> constant is. I don’t see any compelling reason to propose a change to that. >> >> -David > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
