>From the user's standpoint, a crash is the worst thing possible, and should >always be avoided. A failure doesn't need to be silent for user, the app can >still communicate that there was an error with some kind of human readable >message, and the developer can still be informed via any service that provides >logging of non-fatal errors (there are many, most of them free).
During development, a crash can be informative, and that's what "assert" and things like that are for: even if I still prefer to not crash, and handle invariants by using specifically crafted types, I can understand the need for crashing in development, and from that standpoint I'd definitely support a proposal which goal is to make crashes caused by forced unwrapping more informative for the developer, or to force the developer to make them more informative (by substituting "!" with "!!"). The reason why I'm not completely convinced is the fact that there's already "fatalError", and its presence already clearly indicates in the code that something could trap there, in a verbally-appropriate way. In this sense a new operator could encourage practices that in my opinion should not be encouraged. Elviro > Il giorno 29 giu 2017, alle ore 12:12, David Hart <[email protected]> ha > scritto: > > > > On 29 Jun 2017, at 09:19, Elviro Rocca via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> >>> Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution >>> <[email protected] <mailto:[email protected]>> ha scritto: >>> >>> Finally, there’s a woolier justification: there’s an often-touted >>> misconception out there that force unwraps are bad, that they were only >>> created to accommodate legacy apps, and that force-unwrapping is always bad >>> and you should never do it. This isn’t true – there are many good reasons >>> to use force unwrap (though if you reaching for it constantly it’s a bad >>> sign). Force-unwrapping is often better than just whacking in a default >>> value or optional chaining when the presence of nil would indicate a >>> serious failure. Introduction of the `!!` operator could help >>> endorse/encourage the use of “thoughtful” force-unwrapping, which often >>> comes with a comment of the reasoning why it’s safe (of why the array can’t >>> be empty at this point, not just that it is empty). And if you’re going to >>> write a comment, why not make that comment useful for debugging at the same >>> time. >>> >> >> If one could still just "!" I'm not sure that the "!!" would really >> encourage a more thoughtful force unwrapping. Almost every crash related to >> a force unwrap that I see from Swift beginners is 100% due to the fact that >> adding and exclamation point makes the code compile, so they add it. >> >> Also, I strongly disagree with your statement that the idea that >> force-unwraps are bad is a misconception: if something is Optional, there's >> a reason why it is, otherwise it would not be Optional at all, and that's >> the reason why Optional exists in Swift and represents a substantial >> technological advancement over Objective-C. Using an Optional means that we >> are actually adding a thoughtful information to an instance: it could be >> there, or it could not, and that's perfectly fine. Crashing an app in >> production for a force-unwrap results in the poorest user experience ever, >> and it should never happen. > > If forced unwraps are only used in instances where you specifically expect > the optional to not be nil, it is essentially sugar for a guard with > preconditionFailure: it is used to enforce invariants the app should never > break. It is very similar to a trap when accessing an out of bounds index in > an array. In those cases, I actually prefer it crashing than having the app > silently fail for the user, and you never finding out. > > I try to limit my use of optional unwrapping but there are sometimes quite > useful. IMHO, they are not inherently bad, but can be badly used. > >> I feel compelled to link another article, where Soroush Khanlou shows that >> sometimes the bare semantics of an Optional (that is, something is there or >> not) is not enough: http://khanlou.com/2017/03/that-one-optional-property/ >> <http://khanlou.com/2017/03/that-one-optional-property/> >> >> I also disagree with the idea that the "?? fatalError()" alternative suffers >> from cognitive dissonance, for the following reasons: >> >> - on the right of the "??" operator there could be both an Optional or a >> non-Optional, which would result in a different type for the resulting >> instance; >> - fatalError() by itself is an operation that changes the meaning of a >> function, making it non-total, and its very name conveys a clear meaning to >> a person that reads the code, thus it really doesn't seem to me that "?? >> fatalError()" could be misinterpreted; >> >> Anyway, it would be interesting to consider "!! message" as an alternative >> to "!", thus forcing the user to at least do extra effort: that could >> discourage a light use of !. >> >> >> Elviro >> _______________________________________________ >> 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
