> On 29 Jun 2017, at 12:37, Elviro Rocca <[email protected]> wrote: > > 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.
I understand your wish to never crash in production. But I think it’s an ideal that is quite far from the day to day development practices of many developers. If the philosophy of the Standard Library was to avoid all production crashes, we wouldn’t have the following: Implicitly unwrapped optionals Optional explicit unwrapping fatalError precondition The fact is that we have those tools and that they are useful and used. I salute your wish to ban all of the above in an effort to avoid all crashes in production, but IMHO, it’s a style that is best enforced using a linter. > Elviro > >> Il giorno 29 giu 2017, alle ore 12:12, David Hart <[email protected] >> <mailto:[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
