Crashlytics 是否遇到 assertionFailure 崩溃？
Does Crashlytics encounter assertionFailure as crash?
我有点困惑，找不到关于这个案例的正确信息。正如我们从文档中所知：
Use this function to stop the program, without impacting the
performance of shipping code, when control flow is not expected to
reach the call—for example, in the default case of a switch where you
have knowledge that one of the other cases must be satisfied. To
protect code from invalid usage in Release builds, see
preconditionFailure(_:file:line:).
但是，当我的 asserionFailure 触发时，我在 Crashlytics 中收到崩溃报告。
Crashed: com.apple.main-thread
0 libswiftCore.dylib 0x1b0c15efc specialized _assertionFailure(_:_:file:line:flags:) + 440
1 libswiftCore.dylib 0x1b0a316b8 assertionFailure(_:file:line:) + 96
2 OneFit 0x100a3d238 AdditionalUserInfoRouter.enqueueRoute(with:animated:completion:) + 64 (AdditionalUserInfoRouter.swift:64)
3 OneFit 0x100a53040 protocol witness for MVVMRouter.enqueueRoute(with:animated:completion:) in conformance AdditionalUserInfoRouter + 4374458432 (<compiler-generated>:4374458432)
4 OneFit 0x100638224 MVVMRouter.enqueueRoute(with:) + 32 (MVVMRouter.swift:32)
5 OneFit 0x100a6a6c8 closure #2 in AdditionalUserInfoViewModel.close() + 132 (AdditionalUserInfoViewModel.swift:132)
6 OneFit 0x100a676a0 thunk for @escaping @callee_guaranteed (@guaranteed [Subscription]) -> (@error @owned Error) + 4374541984 (<compiler-generated>:4374541984)
7 OneFit 0x100a6fb94 partial apply for thunk for @escaping @callee_guaranteed (@guaranteed [Subscription]) -> (@error @owned Error) + 4374576020 (<compiler-generated>:4374576020)
8 PromiseKit 0x10344d048 $s10PromiseKit8ThenablePAAE4done2on5flags_AA0A0CyytGSo17OS_dispatch_queueCSg_8Dispatch0J13WorkItemFlagsVSgy1TQzKctFyAA6ResultOyARGcfU_yycfU_ + 64
9 PromiseKit 0x103426614 $sIeg_IeyB_TR + 28
10 libdispatch.dylib 0x1a35a9610 _dispatch_call_block_and_release + 24
11 libdispatch.dylib 0x1a35aa184 _dispatch_client_callout + 16
12 libdispatch.dylib 0x1a355c1d0 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1044
13 CoreFoundation 0x1a385a3c4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
14 CoreFoundation 0x1a38553b8 __CFRunLoopRun + 2004
15 CoreFoundation 0x1a38548bc CFRunLoopRunSpecific + 464
16 GraphicsServices 0x1ad6c0328 GSEventRunModal + 104
17 UIKitCore 0x1a78ea6d4 UIApplicationMain + 1936
18 OneFit 0x1003b3784 main + 39 (AppDelegate.swift:39)
19 libdyld.dylib 0x1a36df460 start + 4
Crashlytics 将断言记录为崩溃还是我遇到了真正的崩溃？
更新： Firebase/Crashlytics 支持回复：
I don't know of any particular Crashlytics-related behavior around
assertionFailure, and unless it's terminating the main app thread I
would not expect us to view it as a crash. I see there's already an
answer on the Whosebug post - does that clear things up?
不应在具有 -O 优化级别的 release 构建中启用断言。这意味着在最终的 release 代码中会有一个空行，因此 Crashlytics 不会崩溃。
仔细检查您的目标 build settings，如果您是从头开始创建它或从调试中复制它，您可能启用了断言。
来自docs：
In playgrounds and -Onone builds (the default for Xcode’s Debug
configuration), stop program execution in a debuggable state after
printing message.
In -O builds, has no effect.
In -Ounchecked builds, the optimizer may assume that this function is
never called. Failure to satisfy that assumption is a serious
programming error.
我有点困惑，找不到关于这个案例的正确信息。正如我们从文档中所知：
Use this function to stop the program, without impacting the performance of shipping code, when control flow is not expected to reach the call—for example, in the default case of a switch where you have knowledge that one of the other cases must be satisfied. To protect code from invalid usage in Release builds, see preconditionFailure(_:file:line:).
但是，当我的 asserionFailure 触发时，我在 Crashlytics 中收到崩溃报告。
Crashed: com.apple.main-thread
0 libswiftCore.dylib 0x1b0c15efc specialized _assertionFailure(_:_:file:line:flags:) + 440
1 libswiftCore.dylib 0x1b0a316b8 assertionFailure(_:file:line:) + 96
2 OneFit 0x100a3d238 AdditionalUserInfoRouter.enqueueRoute(with:animated:completion:) + 64 (AdditionalUserInfoRouter.swift:64)
3 OneFit 0x100a53040 protocol witness for MVVMRouter.enqueueRoute(with:animated:completion:) in conformance AdditionalUserInfoRouter + 4374458432 (<compiler-generated>:4374458432)
4 OneFit 0x100638224 MVVMRouter.enqueueRoute(with:) + 32 (MVVMRouter.swift:32)
5 OneFit 0x100a6a6c8 closure #2 in AdditionalUserInfoViewModel.close() + 132 (AdditionalUserInfoViewModel.swift:132)
6 OneFit 0x100a676a0 thunk for @escaping @callee_guaranteed (@guaranteed [Subscription]) -> (@error @owned Error) + 4374541984 (<compiler-generated>:4374541984)
7 OneFit 0x100a6fb94 partial apply for thunk for @escaping @callee_guaranteed (@guaranteed [Subscription]) -> (@error @owned Error) + 4374576020 (<compiler-generated>:4374576020)
8 PromiseKit 0x10344d048 $s10PromiseKit8ThenablePAAE4done2on5flags_AA0A0CyytGSo17OS_dispatch_queueCSg_8Dispatch0J13WorkItemFlagsVSgy1TQzKctFyAA6ResultOyARGcfU_yycfU_ + 64
9 PromiseKit 0x103426614 $sIeg_IeyB_TR + 28
10 libdispatch.dylib 0x1a35a9610 _dispatch_call_block_and_release + 24
11 libdispatch.dylib 0x1a35aa184 _dispatch_client_callout + 16
12 libdispatch.dylib 0x1a355c1d0 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1044
13 CoreFoundation 0x1a385a3c4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
14 CoreFoundation 0x1a38553b8 __CFRunLoopRun + 2004
15 CoreFoundation 0x1a38548bc CFRunLoopRunSpecific + 464
16 GraphicsServices 0x1ad6c0328 GSEventRunModal + 104
17 UIKitCore 0x1a78ea6d4 UIApplicationMain + 1936
18 OneFit 0x1003b3784 main + 39 (AppDelegate.swift:39)
19 libdyld.dylib 0x1a36df460 start + 4
Crashlytics 将断言记录为崩溃还是我遇到了真正的崩溃？
更新： Firebase/Crashlytics 支持回复：
I don't know of any particular Crashlytics-related behavior around assertionFailure, and unless it's terminating the main app thread I would not expect us to view it as a crash. I see there's already an answer on the Whosebug post - does that clear things up?
不应在具有 -O 优化级别的 release 构建中启用断言。这意味着在最终的 release 代码中会有一个空行，因此 Crashlytics 不会崩溃。
仔细检查您的目标 build settings，如果您是从头开始创建它或从调试中复制它，您可能启用了断言。
来自docs：
In playgrounds and -Onone builds (the default for Xcode’s Debug configuration), stop program execution in a debuggable state after printing message.
In -O builds, has no effect.
In -Ounchecked builds, the optimizer may assume that this function is never called. Failure to satisfy that assumption is a serious programming error.