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 > <swift-evolution@swift.org> 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 <da...@owensd.io >> <mailto:da...@owensd.io>> wrote: >> >> >>> On Dec 18, 2015, at 4:38 PM, Ricardo Parada <rpar...@mac.com >>> <mailto:rpar...@mac.com>> 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 > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
