Когда, где и как их использовать

Первая настоящая IDE появилась в 1991 году. Она была частью платформы Microsoft Visual Basic. Apple потребовалось более десяти лет, чтобы догнать Xcode в 2003 году. Конечно же, IDE, стандарты Intergraded Development Environment или, как некоторые утверждают, Intergraded Debugging Environment. Отладка — это то, на что программисты тратят как минимум половину своего времени. Конечно, также говорят, что программисты могут тратить до пятидесяти процентов своего времени на документирование программ — хотя в этот факт мне трудно поверить, кроме того, если бы оба были правдой, когда бы не осталось времени на кодирование.

На этой мысли человек по имени Джеймс Гослинг [изобретатель языка программирования Java] придумал идею, которая поможет объединить обе довольно трудоемкие задачи с оператором под названием assert. Утверждение — это фрагмент кода, который одновременно является средством его тестирования и документирования. Языковая функция, которая наверняка была скопирована в Swift.

Утверждения

Утверждения в своей самой базовой форме в обоих языках не только проверяют значение, но и, в отличие от оператора «если», эффективно документируют предположение об этом. Более того, в среде XCode они рассматриваются как комментарии. Включается в бинарный файл только при компиляции в режиме отладки, а не в производственный код — хотя это еще не все. Присоединяйтесь ко мне, чтобы узнать больше.

Базовый синтаксис

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

struct ContentView: View {
var body: some View {
Text("Go Game")
.padding()
.onTapGesture {
returnMembers([1])
}
}
func returnMembers(_ members:[Int]) {
assert(members.count > 1, "Must contain @least 2 numbers")
print("execute")
}
}
view raw assert1.swift hosted with ❤ by GitHub

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

Синтаксис следующего уровня

Следующим в лиге утверждений является это, которое, я думаю, нужно преподавать в школе кодирования. Оставаясь в теме игры, мой код просит вернуть значение уровня. Как я уверен, вы знаете, что оператор switch должен охватывать все возможные значения, и поэтому, даже если вы знаете, что уровень 4 не может существовать, он настаивает на том, что что-то должно идти по умолчанию. Так что же может быть лучше, чем утверждение о том, что это значение невозможно [в отличие от оператора break или print]? Код, который снова войдет в отладочную версию, но не в рабочую.

import SwiftUI
struct ContentView: View {
var body: some View {
Text("Go Game")
.padding()
.onTapGesture {
returnLevel(4)
}
}
func returnLevel(_ code:Int) {
switch code {
case 1:
print("beginner")
case 2:
print("standard")
case 3:
print("advanced")
default:
assertionFailure("Something is broken")
}
}
}
view raw assert2.swift hosted with ❤ by GitHub

Терминальный синтаксис

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

struct ContentView: View {
var body: some View {
Text("Go Game")
.padding()
.onTapGesture {
stopEverything()
}
}
func stopEverything() {
assertionFailure()
}
}
view raw assert3.swift hosted with ❤ by GitHub

Новый синтаксис

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

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

Окончательно

У вас есть этот, который приведет к сбою отладочного и производственного кода. Идея, стоящая за этим, насколько я понимаю, заключается в том, что вы будете использовать его в качестве последнего средства для защиты целостности какого-либо ресурса, который в противном случае был бы поврежден, поэтому вы фактически вызываете сбой.

  • fatalError("foo") всегда будет падать, что бы ни случилось -

Но слово предупреждения для последнего из них — когда вы вызываете fatalError в своем коде, путь вашего исполняемого файла копируется в сам двоичный файл для целей отладки. Путь, который вы, возможно, не захотите рекламировать миру в целом в производственной среде.