应用主动崩溃的适用场景及ResoCoder代码中getOrCrash用法咨询

• 遇到不可恢复的核心逻辑故障时：比如账户核心字段缺失、交易模块核心参数非法，继续运行只会产生脏数据、资金损失等更严重的后果，主动崩溃可以及时止损，避免故障范围扩大。
• 开发/测试阶段的缺陷快速暴露场景：主动崩溃可以第一时间把不符合预期的逻辑问题抛出来，避免隐性缺陷被忽略后流到线上环境。
• 检测到高风险安全问题时：比如应用被注入篡改、核心加密模块校验失败，继续运行会导致用户敏感数据泄露，主动崩溃可以规避安全风险。
• 已经做过前置校验的内部逻辑分支：比如入口层已经完成了参数合法性校验，后续内部逻辑如果依然走到非法分支，说明代码逻辑出现了意料之外的漏洞，主动崩溃可以快速定位问题，避免bug长期潜伏。

你提到的是Dart语言的DDD风格值对象校验代码，完整片段如下：

T getOrCrash() {
    // id = identity - same as writing (right) => right
    return value.fold((f) => throw UnexpectedValueError(f), id);
}
Option<ValueFailure<dynamic>> get failureOption {
    return body.failureOrUnit
        .andThen(color.failureOrUnit)
        .andThen(todos.failureOrUnit)
        .andThen(
          todos
              .getOrCrash()      // 此处触发崩溃是否合理？为什么要这样设计？
              .map((todoItem) => todoItem.failureOption)
              .filter((o) => o.isSome())
              .getOrElse(0, (_) => none())
              .fold(() => right(unit), (f) => left(f)),
        )
        .fold((f) => some(f), (_) => none());
}

这个设计是完全合理的，核心原因如下：

1. 前置校验已经保证了合法性：在调用getOrCrash之前，代码已经执行了todos.failureOrUnit，这个方法会在校验不通过时直接返回错误，不会走到后续的andThen分支。也就是说只要能执行到getOrCrash这一行，todos理论上一定是合法有效的，不会出现校验失败的情况。
2. 崩溃是为了暴露代码漏洞：如果这个位置真的触发了崩溃，只能说明你写的failureOrUnit校验逻辑本身有问题，属于代码编写缺陷。主动崩溃可以第一时间把这个漏洞暴露出来，而不是把错误吞掉，导致后续出现更难排查的业务异常。
3. 简化代码逻辑：这种设计可以避免在后续逻辑中重复写冗余的合法性校验代码，只要走到当前分支就可以默认值是合法的，代码可读性和可维护性更高。
4. 排查成本更低：崩溃时抛出的UnexpectedValueError会携带明确的错误信息，相比静默失败后业务逻辑异常，这种崩溃的问题定位效率要高很多。

内容的提问来源于stack exchange，提问作者Mariam Albarghouti