Why using implicit unwrap or force unwrap letting the app crash at some stage not beneficial?

青春壹個敷衍的年華 提交于 2020-01-05 04:22:06

问题


My point is at some places we know that the variable won't have nil at all but due to some reason we can't instantiate it in the class's init function so we have to make it optional.

I also know that we can use optional binding or guard techniques to get rid of it easily.

But letting the app crash at some really stupid mistakes because of the implicit unwrap/force unwrap is beneficial for the developers at the developing phase in my opinion.

My example would be:

class TopStoriesViewModelTests: XCTestCase {
    var viewModel: TopStoriesViewModel!

    override func setUp() {
        super.setUp()
        viewModel = TopStoriesViewModel(interactor: MockTopStoriesInteractor())
    }

    func testArticleDidVisited() {
        viewModel.visited = xxxxxx
    }
}

In this case I can make TopStoriesViewModel a ? then guard it or if let it in every test cases, but I feel like it's not necessary. I know I may use viewModel?.xxx too. But this is not the point.

My question is, am I correct on the point that in some certain circumstances such as the example I gave, having it force unwrapped/implicit unwrapped is beneficial.


回答1:


Sure. There any many proper uses of force-unwrapping where a crash will only occur early in development because a mistake has been made and once fixed, the crash won't ever happen again.

A common example is accessing an image from the resource bundle. A line such as:

let imagePath = Bundle.main.path(forResource: "image", ofType: "png")!

should crash in early development if the developer forgot to target image.png properly. Once targeted properly, that line won't crash so there's no reason to deal with an optional path.

Other common examples are outlets. They are usually made implicitly unwrapped because by the time they are used in the view controller's code, they will have been attached. A crash probably means the outlet wasn't connected properly. It gets fixed and there's no more worry. No need to deal with guards or other optional checking.

Last example (there are many more possibilities). When dequeuing a cell from a table view, force-cast the resulting cell to the custom cell type. No need for a guard. I see code here all the time that uses a guard with as? to throw a fatal error if the cast fails. Just force-cast. You get the same crash with less code. Once the table view and storyboard are correct, the force-cast won't fail.

Having said this, newer Swift developers should avoid the ! character on their keyboard for a while. Knowing when to safely use it is a learned skill.

If the potential crash is fully in the control of the developer and the crash could only happen because the developer make a mistake, then using ! may be appropriate.

If the potential crash can be caused by unexpected data (JSON parsing, user input, etc.), then never use !. Code defensively in those cases.

tl;dr - yes, there are plenty of cases where forced-unwraps, forced-casts, and implicitly unwrapped variables are the correct choice.



来源:https://stackoverflow.com/questions/50869124/why-using-implicit-unwrap-or-force-unwrap-letting-the-app-crash-at-some-stage-no

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!