1. 规则验证是准确性的基础

规则验证是业务稳定性的重要保障手段，通过规则验证，可以验证和确保系统或业务逻辑的正确性和合规性，避免潜在的错误和问题。而规则的遗漏往往会伴随着线上bug的出现。

相信每个开发人员都曾面对过以下情况：

• 未对入参进行非空判断，在执行逻辑时导致空指针异常（NullPointerException，简称NPE）;
• 未正确验证用户权限，导致未授权操作发生，普通用户也能执行该操作，最终产生安全问题；
• 在数据被存储到数据库时，没有进行完整性验证，导致无效数据被存储；
• 在业务逻辑中，未对可能抛出的异常进行适当的处理，导致系统无法正常运行；
• …

可见，验证对流程极为重要，不合理的输入会导致严重的业务问题。同时错误数据的影响也比想象中的大得多：

• 可能会导致整个写流程异常中断；
• 错误数据入库后，会对所有的读操作造成致命的伤害；
• 上游系统数据错误，下游系统纷纷“崩溃”；

2. 防御式编程

如何避免上述情况的发生，答案就在 防御式编程。

防御式编程（Defensive Programming）是一种软件开发方法，目的是在代码中预测可能出现的异常和错误情况，并用适当的措施对其进行处理，从而提高软件的健壮性和稳定性。通过防御式编程，软件开发人员可以在软件功能相对复杂的情况下，避免和减少由于程序错误所导致的不可预测的行为和不良影响，并保障软件在部署和运行时的正确性和稳定性，提高软件可靠性和安全性。

防御式编程的核心思想是在代码中尽量考虑一切可能出现的异常和错误情况，并在代码中针对这些异常和错误情况做出相应的处理。例如，可以使用异常捕获机制处理可能出现的异常，充分利用代码注释和约束条件来规范输入数据，使用断言（assert）来检查代码中的前置条件和后置条件等。

概念过于繁琐，简单理解：防御式编程就是：

1. 不要相信任何输入，在正式使用前，必须保证参数的有效性；
2. 不相信任何处理逻辑，在流程处理后，必须保证业务规则仍旧有效；

对输入参数保持怀疑，对业务执行的前提条件保存怀疑，对业务执行结果保持怀疑，将极大的提升系统的准确性！

3. 异常中断还是返回值中断？

在规则校验场景，优先使用异常进行流程中断。

3.1. 异常中断才是标配

在没有提供异常的编程语言中，我们只能使用特殊返回值来表示异常，这样的设计会将正常流程和异常处理流程混在一起，让语言失去了可读性。比如在 C 中，通用会使用 -1 或 NULL 来表示异常情况，所以在调用函数第一件事便是判断 result 是 NULL 或 -1，比如以下代码：

void readFileAndPrintContent(const char* filename) {
    FILE* file = fopen(filename, "r");
    if (file == NULL) {
        // 文件无法打开，返回异常状态
        fprintf(stderr, "Failed to open the file.\n");
        return;  // 直接返回，表示发生异常
    }
    char line[256];
    while (fgets(line, sizeof(line), file) != NULL) {
        printf("%s", line);
    }
    fclose(file);
}