什么时候应该使用断言和前提条件，什么时候可以使用保护语句，强制展开和错误处理?

本文介绍了什么时候应该使用断言和前提条件，什么时候可以使用保护语句，强制展开和错误处理?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我已经阅读了中的"precondition"和"assert"之间的区别迅速.但是，(断言的不同解压缩方式，例如guard& ! + )与断言之间仍然没有清晰的界线.

I've already read Difference between "precondition" and "assert" in swift. But still can't draw a clear line between the (different ways of unwrapping ie guard & ! + error handling) vs assertions.

如果我希望我的应用程序不再运行，我是否不能仅仅强制打开某些内容并替代前提条件?

If I want my application to no longer work, can't I just force unwrap something and substitute as for a precondition?

是因为我们想要想要停止/退出应用程序，并且基本上不希望任何控制流或状态发生变化，因此我们使用了也会发生的断言/前提条件可以轻松记录人类可读的消息(帮助我们避免不断编写print)?
我们使用assert至关重要的事情是，guard语句最终是一个控制流系统，即使您的函数提早返回，也不一定意味着您的应用程序应该崩溃.

Is it because we want to stop/exit the app and basically don't want any control flow or state changing and therefore we use asserts/preconditions which also happens to come with easy logging of human readable messages (helps us to not constantly write prints)?
Things that we use asserts for have are vital, guard statements are eventually a control flow system that even if your function returns early doesn't necessarily mean your app should crash.

如果它超出了nil之类的东西，例如您想要一个 String ，并且用户给您一个 Int ，那么您可以使用错误处理.

And if it's anything beyond nils like you want a String and the user is giving you an Int then you can use error handling.

我不反对意见，我只是想了解断言为上述替代方案提供了什么便利.编号列表是我的问题的核心.

I'm not after opinions, I'm asking this only to understand what convenience assertions provide over the mentioned alternatives. The numbered list is the core of my question.

推荐答案

错误是流控制的一种形式，与if和while相当.特别是，它们涉及连贯的消息发送和提早退出.这个想法是立即结束当前作用域并将控制权返回给调用方，告诉调用方出了点问题".
- Errors are a form of flow control, on a par with if and while. In particuar, they involve coherent message sending and early exit. The idea is to wind up the current scope immediately and return control to the caller, telling the caller "something went wrong".
  断言是一种立即崩溃的方法.
  Assertions are a way to crash immediately.
  因此，它们属于完全不同的概念世界.错误是指可能实时出错的事情，我们需要从中连贯地恢复.断言用于永远不会出错的事情，对此我们感到非常强烈，以至于我们甚至不希望在这种情况下将该程序发布给世人，并且可以在无法使用错误的地方使用它.
  Thus they belong to completely different conceptual worlds. Errors are for things that can go wrong in real time, from which we need to recover coherently. Assertions are for things that should never go wrong, and about which we feel so strongly that we don't want the program even to be released into the world under these circumstances, and can be used in places where Errors can't be used.
  来自我自己的代码的示例:
  Example from my own code:
```
final class Board : NSObject, NSCoding, CALayerDelegate {
    // ...
    fileprivate var xct : Int { return self.grid.xct }
    fileprivate var yct : Int { return self.grid.yct }
    fileprivate var grid : Grid // can't live without a grid, but it is mutable
    // ...
    fileprivate lazy var pieceSize : CGSize = {
        assert((self.xct > 0 && self.yct > 0), "Meaningless to ask for piece size with no grid dimensions.")
        let pieceWidth : CGFloat = self.view.bounds.size.width / (CGFloat(self.xct) + OUTER + LEFTMARGIN + RIGHTMARGIN)
        let pieceHeight : CGFloat = self.view.bounds.size.height / (CGFloat(self.yct) + OUTER + TOPMARGIN + BOTTOMMARGIN)
        return CGSize(width: pieceWidth, height: pieceHeight)
    }()
    // ...
}
```
  如果曾经调用的网格尺寸为零，则我的整个程序出了点问题.测试运行时错误不是问题.该程序本身基于错误的算法.这就是我要检测的.
  If pieceSize is ever called with a zero grid dimension, something is very wrong with my entire program. It's not a matter of testing for a runtime error; the program itself is based on faulty algorithms. That is what I want to detect.
  
  这篇关于什么时候应该使用断言和前提条件，什么时候可以使用保护语句，强制展开和错误处理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！