嵌入式C++处理软件异常时中断的默认行为及nlohmann json相关疑问

• 核心结论：nlohmann JSON库本身不会在异常抛出或处理过程中显式禁用硬件中断。库的代码和官方文档都未提及任何系统级中断控制逻辑，它只是标准C++异常的使用者，不涉及中断屏蔽操作。

• C++异常的默认行为：在标准C的嵌入式实现中，异常抛出与栈展开过程不会自动屏蔽硬件中断。异常处理属于用户态的软件流程，硬件中断的触发和响应由CPU内核、中断控制器独立管理，和C异常机制本身无绑定关系。只有当代码中显式调用了关中断指令（如ARM的CPSID I、x86的cli），或是编译器/RTOS有非标准的特殊配置时，才会出现中断被阻塞的情况——这类特殊配置一定会在系统文档中有明确说明。

• 性能相关说明：

  • 若异常处理流程耗时较长（比如复杂的栈展开、大量资源清理），会占用CPU时间片，导致中断响应延迟，但这并非中断被阻塞，只是CPU在优先处理异常流程，未及时响应中断。这种延迟和普通长任务执行导致的中断延迟本质相同，和异常机制本身无关。
  • 真正的“中断阻塞”（中断被屏蔽）只会发生在显式执行关中断操作的场景，nlohmann JSON库的代码中不存在这类逻辑。

• 验证建议：

  • 可以在中断服务程序（ISR）中添加硬件触发操作（比如翻转GPIO引脚），同时在代码中主动触发nlohmann JSON的异常（例如访问不存在的JSON键），用示波器观察GPIO的触发时机，即可直观确认中断是否被阻塞。
  • 查阅你所使用的RTOS或编译器文档，确认C++异常处理的配置是否会影响中断状态——部分RTOS可能在任务上下文抛出异常时调整中断屏蔽级别，但这属于系统层面的设置，和nlohmann库无关。

内容的提问来源于stack exchange，提问作者Owen Petersen