移动应用中的 Non-Fatal Error — 本质、类型及错误处理

什么是 Non-Fatal Error

Non-Fatal Error — 是一种不会导致进程终止的异常或错误状态。应用程序继续运行，但可能处于不正确状态：数据未加载、请求未发送、界面元素未显示。用户要么没有注意到错误，要么看到消息后继续使用应用程序。

关键特征

非致命错误总是给程序留下恢复路径。错误处理器 可以提供替代数据、重试操作或显示界面占位符。主要任务是防止崩溃并将用户体验维持在可接受的水平。开发人员必须在每个 catch 块中明确预见到恢复场景。

在应用程序稳定性中的作用

根据 Instabug 2024 的数据，65% 的用户在两次失败交互后会删除应用程序。被忽视的 non-fatal 错误会累积并降低整体工作质量。系统性地记录和修复非致命错误是提高留存率和改善应用商店用户评价的直接途径。

非致命错误的类型

网络错误 — 是移动应用中最常见的 non-fatal 错误类型。连接超时、网络丢失、服务器状态码错误——所有这些情况都会被捕获并处理而不会崩溃。用户会看到服务不可用的消息，并提示重试。对于网络错误，典型的模式是指数退避重试。

数据验证错误

错误的服务器响应格式、缺少必填字段、错误的数据类型——解析错误 如果应用程序正确处理错误数据，则是非致命的。典型的方法是使用默认后备值，并记录带有请求上下文的解析错误，以便稍后在服务器上进行分析。

UI 渲染错误

图片加载问题、错误的字体、布局错误——这些都不是致命的，但会降低用户体验。占位图片 和后备值可以避免空白屏幕，并使错误不那么明显。在 React Native 中，UI 错误使用 Error Boundary 并显示备用组件。

业务逻辑和状态错误

计算错误、状态不一致、屏幕之间的错误转换——逻辑错误 通常不会导致崩溃，但会导致应用程序行为不正确。如果没有系统性的记录和监控，它们更难被发现，因为它们不会生成崩溃报告，并且在用户投诉之前一直不被注意。

Non-Fatal Error 与 Fatal Error：对比

Non-Fatal Error 与 fatal 的不同之处在于它给程序留下继续工作的可能性。Fatal error 是一种应用程序无法恢复的状态：空指针解引用、堆栈溢出、内存不足。Non-fatal 错误可以被捕获、处理并继续执行，而 fatal error 则需要重新启动应用程序。

non-fatal 和 fatal 之间的界限可能取决于实现。网络超时 在一个应用程序中作为 non-fatal 处理（1-2 秒后重试请求），在另一个应用程序中可能是致命的（没有处理器时崩溃）。高质量的错误处理将潜在致命的情况转化为非致命的情况，从而提高应用程序的稳定性。设计错误处理系统是开发高可靠性移动应用程序时关键的架构任务之一。内置的监控系统允许团队在非致命错误影响大量用户之前快速发现并修复它们。

记录 non-fatal 错误

Firebase Crashlytics — 是移动应用程序中记录非致命错误的主要工具。recordException 方法允许在不停应用程序运行的情况下，记录带有完整堆栈跟踪和执行上下文的 non-fatal 异常。与崩溃报告不同，recordException 可以在代码的任何位置调用以记录捕获的异常。

fun fetchUserData(userId: String) {
    try {
        val response = apiService.getUser(userId)
        updateUI(response)
    } catch (e: IOException) {
        Crashlytics.log("Network error for user $userId")
        Crashlytics.recordException(e)
        showRetryDialog()
    } catch (e: JsonParseException) {
        // Non-fatal：使用备用数据
        Crashlytics.recordException(e)
        showFallbackContent()
    }
}

// 使用用户密钥进行记录
Crashlytics.setCustomKey("screen", "Profile")
Crashlytics.setCustomKey("api_version", "v3")

Sentry — 是 Crashlytics 的替代方案，具有更详细的 non-fatal 错误诊断功能。Sentry SDK 提供了 captureException 方法，用于将异常详细信息发送到服务器。Sentry 的主要优势是将类似的 non-fatal 错误分组到同一个 issue 中，分析重复频率以及以面包屑形式提供的执行上下文——错误之前用户操作的顺序。

记录 non-fatal 错误的标准

并非所有 non-fatal 错误都需要记录。预期状态 — 没有连接时的网络故障——可以选择性地记录。意外错误 — 处理代码中的 NullPointerException、错误的数据格式、logic error——应该始终记录。每个团队根据应用程序的背景确定重要性阈值：平均每 1000 名用户每天 10 到 20 个独特的 non-fatal 错误被认为是正常的。重要的是设置关于 non-fatal 错误数量急剧增加的警报——这可能表明新版本 API 存在问题或发布后出现回归。

在代码中处理 non-fatal 错误

基本的处理机制是 try-catch，它捕获异常并执行恢复代码。对于网络操作，典型的模式是指数退避重试。对于解析错误——使用默认后备值并记录上下文以便在服务器端进行分析。

func loadImage(from url: URL) -> UIImage? {
    do {
        let data = try Data(contentsOf: url)
        return UIImage(data: data)
    } catch {
        Logger.shared.logError(error: "Image load failed: \(url)")
        return UIImage(named: "placeholder")
    }
}

func performRequest() async throws -> Data {
    var lastError: Error? = nil
    for attempt in 0..<3 {
        do {
            return try await URLSession.shared.data(from: url)
        } catch {
            lastError = error
            try await Task.sleep(UInt64(pow(2, attempt)) * 1_000_000_000)
        }
    }
    throw lastError ?? URLError(.unknown)
}

Result 类型 — 是一种无需异常的替代方法。函数返回带有 Success 和 Failure 变体的密封类 Result。调用代码显式处理两个变体，从而消除了未处理的错误。Result 类型在 Kotlin（标准库中的 Result）和 Swift（Result）中流行，用于在类型层面上显式处理 non-fatal 状态。

Non-fatal 错误的后备策略

对于每种类型的 non-fatal 错误，都应该预见到 恢复策略：网络错误时加载缓存数据，解析错误时使用默认值，UI 错误时重新初始化组件。好的做法是向用户显示包含错误消息的 toast 或 snackbar，但不要完全阻止与应用程序的交互。重要的是区分可恢复（recoverable）和不可恢复的错误——对于后者，恢复策略将不同，例如建议重新启动屏幕或清除数据。缓存先前成功状态通常是移动平台上处理 non-fatal 错误最简单和最有效的方法。