런타임에 일어나는 일을 체크합니다

디버그 할 때만 넣어서 쓰는건가..? (X)

공통

• 코드 작성자의 가정과 예상을 코드로 표현할 수 있는 방법입니다.
• 코드 안에서 문서화 형태로 코드를 작성할 수 있습니다.
• 대응할 수 있거나 예상되는 에러에 사용되지 않습니다.
  • 위와 같은 에러는 기존의 에러 처리 방식인 throw, do-catch 를 사용합니다.
  • Because a failed assertion or precondition indicates an invalid program state, there’s no way to catch a failed assertion

Using assertions and preconditions isn’t a substitute for designing your code in such a way that invalid conditions are unlikely to arise. However, using them to [enforce valid data and state] causes your app to terminate more predictably if an invalid state occurs, and helps make the problem easier to debug. Stopping execution as soon as an invalid state is detected also helps limit the damage caused by that invalid state.

Assertions

• 개발 도중에 일어나는 실수와 잘못된 가정을 찾아내는 것을 도와줍니다.
• 디버그 빌드에서만 평가됩니다.
  • 따라서 아무리 많이 추가해도 배포 빌드의 성능에 영향을 주지 않습니다.

Preconditions

• 배포 빌드에서 이슈를 발견할 수 있도록 도와줍니다.
  • 디버그 빌드에서도 물론 발견할 수 있고, 플래그 값을 통해 동작을 조정할 수 있습니다.

궁금한 점

• Preconditions 은 FatalError 와 같이 배포 빌드에서도 앱 크래시를 발생시킨다.

  • 둘의 활용 방법에 차이가 없는 것 같다는 의문이 들었다.

  if value == 3 {
  	fatalError()
  }
  
  // 이 둘의 차이가 뭘까?
  
  precondtion( value == 3 )
  

공식 문서 - NOTE

If you compile in unchecked mode (-Ounchecked), preconditions aren’t checked. The compiler assumes that preconditions are always true, and it optimizes your code accordingly. However, the fatalError(:file:line:) function always halts execution, regardless of optimization settings.