"전제조건"과 "주장"의 차이점은?
다른 점이 뭐죠?precondition(condition: Bool, message: String)
그리고.assert(condition: Bool, message: String)
스위프트에서?
제가 보기엔 둘 다 똑같아 보여요.우리는 어떤 맥락에서 하나를 다른 하나보다 사용해야 합니까?
assert
테스트 중에 제정신 검사를 위한 것인 반면에precondition
만약 그런 일이 일어난다면 당신의 프로그램이 합리적으로 진행될 수 없다는 것을 의미하는 일들에 대비하기 위한 것입니다.
예를 들어, 당신은 다음과 같이 말할 수 있습니다.assert
어떤 계산으로 (예를 들어, 어떤 범위 내에서) 당신이 버그를 가지고 있는지 빨리 찾기 위해 합리적인 결과를 얻을 수 있습니다.그러나 아웃오브바운드 결과가 유효할 수도 있고 중요하지 않을 수도 있기 때문에 앱을 크래시하지 않아야 합니다(프로그레스 바에 진행률을 표시하기 위해 사용한 것이라고 가정합니다).
반면, 요소를 가져올 때 배열의 첨자가 유효한지 확인하는 것은precondition
. 옵션이 아닌 값을 반환해야 하므로 배열 개체가 잘못된 첨자를 요청할 때 수행할 합리적인 다음 작업이 없습니다.
문서의 전체 텍스트(옵션 클릭 시도)assert
그리고.precondition
Xcode):
전제조건
진전을 이루기 위해 필요한 조건을 확인합니다.
이 기능을 사용하여 배송 코드에서도 프로그램 진행을 방해해야 하는 조건을 탐지할 수 있습니다.
Playground 및 -Onone 빌드(Xcode의 Debug 구성의 기본값): 만약
condition
인쇄 후 디버그 가능한 상태에서 프로그램 실행을 중지하고 거짓으로 평가합니다.message
.In -O 빌드(Xcode의 Release 구성의 기본값): 만약
condition
false, stop 프로그램 실행을 평가합니다.-확인되지 않은 빌드에서,
condition
평가되지는 않지만 최적화자는 다음과 같이 평가할 것으로 가정할 수 있습니다.true
. 확인되지 않은 빌드에서 해당 가정을 충족하지 못하면 심각한 프로그래밍 오류가 됩니다.
주장하다
옵션 메시지를 포함한 기존 C 스타일의 주장입니다.
이 기능은 테스트 중에 활성화되지만 배송 코드의 성능에는 영향을 주지 않는 내부 건전성 검사에 사용합니다.릴리스 빌드에서 잘못된 사용 여부를 확인하려면 다음을 참조하십시오.
precondition
.
Playground 및 -Onone 빌드(Xcode의 Debug 구성의 기본값): 만약
condition
인쇄 후 디버그 가능한 상태에서 프로그램 실행을 중지하고 거짓으로 평가합니다.message
.-O (Xcode 의 릴리스 ),
condition
평가되지 않으며 효과도 없습니다.되지 않은 -에서,
condition
평가되지는 않지만 최적화자는 다음과 같이 평가할 것으로 가정할 수 있습니다.true
되지 않은 확인되지 않은 빌드에서 해당 가정을 충족하지 못하면 심각한 프로그래밍 오류가 됩니다.
스위프트가 주장하는 것을 발견했습니다 - 사라진 매뉴얼이 도움이 될 겁니다
debug release release
function -Onone -O -Ounchecked
assert() YES NO NO
assertionFailure() YES NO NO**
precondition() YES YES NO
preconditionFailure() YES YES YES**
fatalError()* YES YES YES
그리고 스위프트 에볼루션에 대한 흥미로운 토론으로부터.
– assert: 내부 오류가 있는지 자신의 코드를 확인합니다.
– 전제 조건: 고객이 유효한 인수를 제시했는지 확인하기 위한 것입니다.
또한 assertionFailure and Optimization Level(어설션 실패 및 최적화 수준)을 참조하여 사용할 부분에 대해 주의해야 합니다.
precondition
릴리스 모드에서 활성화되어 있으므로 앱을 발송할 때 사전 조건이 실패하면 앱이 종료됩니다.Assert
디버그 모드에서만 기본으로 작동합니다.
NSHipster에서 언제 사용해야 하는지에 대한 훌륭한 설명을 찾았습니다.
주장은 고전 논리학에서 차용한 개념입니다.논리학에서 주장은 증명 안에서 명제에 대한 진술입니다.프로그래밍에서 주장은 프로그래머가 자신이 선언된 장소에서 응용 프로그램에 대해 한 가정을 나타냅니다.
방법이나 기능의 실행의 시작과 끝에서 코드의 상태에 대한 기대를 설명하는 전제조건과 사후조건의 용량에 사용될 때, 주장은 계약을 형성합니다.또한 특정 전제 조건이 실패할 때 실행을 방지하기 위해 런타임에 조건을 적용하는 데도 사용할 수 있습니다.
전제 조건
func precondition(condition: @autoclosure () -> Bool, _ message: @autoclosure () -> String = default, file: StaticString = default, line: UWord = default)
진전을 이루기 위해 필요한 조건을 확인합니다.
- 이 기능을 사용하여 배송 코드에서도 프로그램 진행을 방해해야 하는 조건을 탐지할 수 있습니다.
- Playgrounds and -Onone builds(Xcode의 Debug 구성의 기본값): 조건이 false로 평가되면 메시지 출력 후 디버그 가능한 상태에서 프로그램 실행을 중지합니다.
- In -O builds (Xcode의 Release 구성의 기본값): 조건이 false로 평가되면 프로그램 실행을 중지합니다.
- -선택하지 않은 빌드에서는 조건이 평가되지 않지만 최적화 도구는 참으로 평가된다고 가정할 수 있습니다.확인되지 않은 빌드에서 해당 가정을 충족하지 못하면 심각한 프로그래밍 오류가 됩니다.
주장하다
func assert(condition: @autoclosure () -> Bool, _ message: @autoclosure () -> String = default, file: StaticString = default, line: UWord = default)
옵션 메시지를 포함한 기존 C 스타일의 주장입니다.
이 기능은 테스트 중에 활성화되지만 배송 코드의 성능에는 영향을 주지 않는 내부 건전성 검사에 사용합니다.릴리스 빌드에서 잘못된 사용 여부를 확인하려면 전제 조건을 참조하십시오.
Playgrounds and -Onone builds(Xcode의 Debug 구성의 기본값): 조건이 false로 평가되면 메시지 출력 후 디버그 가능한 상태에서 프로그램 실행을 중지합니다.
- -O 빌드(Xcode의 Release 구성의 기본값)에서는 상태가 평가되지 않으며 아무런 영향이 없습니다.
- -선택하지 않은 빌드에서는 조건이 평가되지 않지만 최적화 도구는 참으로 평가된다고 가정할 수 있습니다.확인되지 않은 빌드에서 해당 가정을 충족하지 못할 경우 심각한 프로그래밍 오류가 발생합니다.
그냥 내 2센트를 추가하고 싶었을 뿐입니다.코드에 원하는 만큼의 주장을 추가할 수 있습니다.이러한 주장을 포함하여 코드를 발송할 수 있습니다.스위프트는 운영 앱에 대해 이러한 코드 블록을 평가하지 않습니다.이는 디버그 모드인 경우에만 평가됩니다.
swift.org 의 이미지도 첨부합니다.
또한 전제 조건의 경우에는 그렇지 않습니다.전제조건과 함께 발송된 코드는 충돌하고 전제조건이 진실로 평가되지 않으면 앱이 종료됩니다.
간단히 말해서, 주장은 디버깅을 위한 것이지만 생산에 영향을 주지 않고 배송될 수 있습니다.주장은 디버그 모드에서는 평가되지만 프로덕션에서는 평가되지 않습니다.
그리고.
전제 조건은 생산 환경에서 예상치 못한 일이 발생하지 않도록 하기 위한 것입니다.이러한 조건은 평가되며 거짓으로 평가될 경우 앱을 종료합니다.
iOS 주장 vs 전제 조건 vs 치명적
일반 규칙:
1. -O(-O, -Osize) - compile out(do not execute) `assert` and `assertionFailure`
2. -Ounchecked(as `SWIFT_OPTIMIZATION_LEVEL = -Ounchecked` or `SWIFT_DISABLE_SAFETY_CHECKS` = true)
2.1 set `condition: true` into `assert(condition: true)` and `precondition(condition: true)` that is why app is not terminated
2.2 optimizer is free to assume that `assertionFailure` and `preconditionFailure` code are never called
오류는 다음과 같습니다.
Experiments2/ViewController.swift:20: Assertion failed: Some error
2022-12-11 15:17:28.772447+0200 Experiments2[95061:10414104] Experiments2/ViewController.swift:20: Assertion failed: Some error
assert(condition: Bool, message: String)
assertionFailure(message: String)
precondition(condition: Bool, message: String)
preconditionFailure(message: String) -> Never
fatalError(message: String) -> Never
Never
Will never be executed
[최적화 레벨(SWIFT_OPTIMIZATION_LEVEL)]
| | -Onone | -O | -O -Ounchecked | -Ounchecked |
|-------------------------------- |:------: |:----------------------------------------: |:----------------------------------------------: |:----------------------------------------------: |
| assert(condition: false) | TRUE | FALSE -O (compile out assert) | FALSE -O (compile out assert) | FALSE -Ounchecked (condition == true) |
| assertionFailure | TRUE | FALSE -O (compiled out assertionFailure) | FALSE -O (compile out assertionFailure) | TRUE or FALSE -Ounchecked(may never be called) |
| precondition(condition: false) | TRUE | TRUE | FALSE -Ounchecked (condition == true) | FALSE -Ounchecked (condition == true) |
| preconditionFailure | TRUE | TRUE | TRUE or FALSE -Ounchecked(may never be called) | TRUE or FALSE -Ounchecked(may never be called) |
| fatalError | TRUE | TRUE | TRUE | TRUE |
TRUE - app is terminated
FALSE - app is not terminated
언급URL : https://stackoverflow.com/questions/29673027/difference-between-precondition-and-assert-in-swift
'programing' 카테고리의 다른 글
ORA-06532: 구독이 제한을 벗어남 (0) | 2023.10.06 |
---|---|
올바른 폴더 경로로 pom.xml의 mainClass를 추가할 수 있습니다. (0) | 2023.10.06 |
Kubernetes 비밀 해독 (0) | 2023.10.06 |
GitLab에서 사용자 지정 Composer 패키지 설치 (0) | 2023.10.06 |
jQuery: 선택한 라디오 버튼에 대해 부모 tr 가져오기 (0) | 2023.10.06 |