Когда следует использовать утверждения и предварительные условия, а когда можно использовать защитные операторы, принудительное развертывание и обработку ошибок?

Question

Я уже прочитал разницу между "предварительным условием" и "утверждать" в быстрой. Но все еще не могу провести четкую грань между (различные способы распаковки, т.е. guard & ! + обработка ошибок) против утверждений.

Если я хочу, чтобы мое приложение больше не работало, могу ли я просто принудительно развернуть что-то и заменить как предварительное условие?

1. Это потому, что мы хотим остановить / выйти из приложения и, в основном, не хотим никакого потока управления или изменения состояния, и поэтому мы используем утверждения / предварительные условия, которые также приходят с легкой регистрацией читаемых человеком сообщений (помогает нам не постоянно писать prints)?
2. Вещи, для которых мы используем утверждения, имеют жизненно важное значение, защитные операторы в конечном итоге становятся системой управления потоком, которая, даже если ваша функция возвращается рано, не обязательно означает, что ваше приложение должно аварийно завершиться.

И если это что-то за nilЕсли вам нужна строка, а пользователь дает вам Int, тогда вы можете использовать обработку ошибок.

РЕДАКТИРОВАТЬ:

Я не за мнениями, я спрашиваю это только для того, чтобы понять, какие утверждения удобства обеспечивают упомянутые альтернативы. Нумерованный список - это суть моего вопроса.

Answer 1

• Ошибки являются формой управления потоком, наравне с if а также while, В частности, они включают в себя последовательную отправку сообщений и ранний выход. Идея состоит в том, чтобы немедленно свернуть текущую область и вернуть управление вызывающему, сообщив вызывающему "что-то пошло не так".

• Утверждения - способ немедленно потерпеть крах.

Таким образом, они принадлежат совершенно другим концептуальным мирам. Ошибки относятся к вещам, которые могут пойти не так в режиме реального времени, от которых нам нужно последовательно восстанавливаться. Утверждения относятся к вещам, которые никогда не должны идти не так, и в отношении которых мы чувствуем себя настолько сильно, что не хотим, чтобы программа даже была выпущена в мир при таких обстоятельствах, и могут использоваться в местах, где ошибки не могут быть использованы.

Пример из моего собственного кода:

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)
    }()
    // ...
}

Если pieceSize когда-либо вызывается с нулевым измерением сетки, что-то не так со всей моей программой. Это не вопрос проверки на ошибки во время выполнения; Сама программа основана на ошибочных алгоритмах. Это то, что я хочу обнаружить.