MicroPython环境读取JSON配置文件的异常处理最佳实践

在从JSON文件读取应用配置时，需要确保读取过程出现任何问题时都能正常加载默认配置。第一版可正常运行的实现代码如下，但实现方式并非最优：

def _recall_settings_v1(self):
    settings = {}
    try:
        with open(_APP_SETTINGS_FILE, "r") as fp:
            try:
                settings = json.load(fp)
            except ValueError:
                # 文件语法无效或已损坏
                pass
    except OSError:
        # 文件读取失败
        pass
    # 能正常读取则加载已保存配置，否则加载默认配置并生成新的配置文件
    if settings:
        self.a = settings["a"]
        self.b = settings["b"]
    else:
        self.a = _DEFAULT_FOR_A
        self.b = _DEFAULT_FOR_B
        # 生成新配置文件
        self._store_settings()

后续优化的第二版代码逻辑更简洁，同样可正常运行，在此提出两个核心疑问：

1. 像第二版这样合并捕获多类异常是否存在副作用？
2. 配置文件的可靠保存与加载是否有通用的规范实现方式？

补充说明：提前通过os模块检查文件是否存在确实可以减少一层异常捕获，但实际上即使文件存在，也无法保证一定可以正常打开或解析。

第二版优化代码如下：

def _recall_settings_v2(self):
    try:
        with open(_APP_SETTINGS_FILE, "r") as fp:
            settings = json.load(fp)
    except (OSError, ValueError):
        # 文件读取失败、文件损坏或语法无效
        # 加载默认配置并生成新配置文件
        self.a = _DEFAULT_FOR_A
        self.b = _DEFAULT_FOR_B
        self._store_settings()
    else:  # 配置读取解析成功
        self.a = settings["a"]
        self.b = settings["b"]

场景补充说明 #

• 代码运行在搭载MicroPython的嵌入式系统上，可导入的模块存在限制。
• 系统要求具备故障容错能力，实际生产环境采用三副本配置文件机制：代码会尝试读写全部三个副本，再通过多数表决函数确定最终加载的配置，上述示例为简化后的单文件处理逻辑。

问题解答 #

1. 合并捕获多类异常的副作用问题 #

第二版合并捕获(OSError, ValueError)的写法在当前代码逻辑下没有功能性副作用，反而比第一版嵌套try的写法可读性更高、逻辑分支更清晰。
唯一需要留意的潜在风险是：如果后续在这个try块中新增其他业务代码，这些代码抛出的OSError或ValueError会被误判为配置加载失败，只要保持try块内仅放置「打开文件、解析JSON」这两行核心逻辑，该风险完全可控。
反而第一版代码存在隐藏逻辑缺陷：如果配置文件是合法JSON但内容为空对象{}，第一版的if settings判断会返回假，直接触发默认配置覆盖，可能冲掉已保存的有效配置；第二版用else分支明确区分「加载流程无异常」和「加载出错走默认逻辑」，反而修复了这个隐患。

2. 嵌入式场景下配置可靠读写的通用实现规范 #

结合MicroPython嵌入式环境的模块限制，不需要引入额外第三方依赖，遵循以下规则即可实现高可靠的配置读写：

• 严格控制异常捕获范围：无论合并捕获还是分开捕获异常，try块的范围要尽可能小，只包裹确定会抛出预期异常的IO、解析代码，不要把配置赋值、其他业务逻辑塞进try块，避免无关异常被误吞，导致非预期的默认配置加载。
• 保证写入操作原子性：保存配置时不要直接覆盖目标文件，先写入同目录下的临时文件，写完后执行fp.flush()+os.sync()（MicroPython的os模块原生支持sync操作），确认数据真正写入Flash存储后，再通过rename操作将临时文件替换为正式配置文件，避免写入过程中掉电损坏原配置文件。
• 增加配置合法性校验：JSON解析成功后不要直接给类属性赋值，先检查所有必填字段是否存在、字段类型是否符合预期、取值是否在合法范围内，只要有一项校验不通过，就判定该配置文件损坏，走降级逻辑。
• 适配三副本容错机制：读取时按顺序逐个副本执行「打开-解析-校验」流程，只要读到一个合法配置就停止读取，无需等待三个副本全部读取完成；写入时先按原子写入规则更新第一个副本，确认写入成功后，再用第一个副本的内容同步更新另外两个副本，避免三个副本同时写入时掉电导致全量配置损坏。
• 损坏文件延迟覆盖：读取某个副本发现损坏时，不要立刻写入默认配置覆盖，先尝试读取其他副本，等拿到合法配置（无论是从其他副本读取到的有效配置，还是最终降级使用的默认配置）之后，再回头修复损坏的副本，避免单次读取错误就丢失已保存的有效配置。

内容的提问来源于stack exchange，提问作者martin's