> > On Mar 21, 2016, at 6:01 AM, Haravikk <[email protected]> wrote: > > I’m a ±1; for the way things are I’m a +1, but I think I’d still prefer to > have typed errors that the compiler can use to check for an exhaustive list, > as it would be easy for a forced conversion to result in unexpected runtime > errors later if you ever need to add a new error type to your .applyAction() > method, since doing so wouldn’t result in any warnings/errors at compile time. >
That is true, but I think that is the intended behavior. Consider the case where applyAction is a method which is to be overridden in by a subclass. If the subclass needs to throw a different type of error, it cannot because the it’s not declared super classes method definition. I ran into this problem the other day in Java. The solution was to throw a runtime exception and in Java it seems that there is a tendency to drift towards more and more runtime exceptions for exactly these types of reasons. The problem with runtime exceptions is that there’s no way to know if they are thrown by a method at it’s call site. At least with the as! operator, people familiar with Swift will immediately recognize that as a potentially app crashing operation. > I agree about catch _ and default; either default should be allowed for > do/catch, or be removed from switches, to promote consistency, but that’s a > separate issue I think. > >> On 20 Mar 2016, at 20:26, Tyler Fleming Cloutier via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> I recall that there was quite a bit of discussion a while back about adding >> typed error declarations for methods that throw for the purpose of >> exhaustive pattern matching on errors. >> >> There were interesting arguments on either side, and I think that the result >> was to maintain the status quo. There’s still the issue of having to add the >> extra catch statement to every do block for exhaustive matches. >> >> Would it be wise to allow force conversion for the cases in which the >> developer believes the match is exhaustive? ie >> >> do { >> let action = chooseAction(game) >> game = try game.applyAction(action) >> } catch let e as ActionError { >> game.failedAction = e >> } catch _ { >> fatalError(“This is an unfortunate bit of noise :/") >> } >> >> becomes >> >> do { >> let action = chooseAction(game) >> game = try game.applyAction(action) >> } catch let e as! ActionError { >> game.failedAction = e >> } >> >> >> Also as a brief aside, it’s not super intuitive to me that the syntax for >> the catch pattern matching wildcard is >> >> catch _ >> >> whereas it is >> >> default >> >> for switches. I think I saw Chris mention somewhere that default was chosen >> because of it’s wide familiarity. Does anyone recall the reason? >> >> Thanks, >> >> Tyler >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
