librealsense 错误处理方案完全指南从异常模型到实战捕获策略【免费下载链接】librealsenseRealSense SDK项目地址: https://gitcode.com/GitHub_Trending/li/librealsenselibrealsenseRealSense SDK以基于异常的exception-based错误处理作为核心设计贯穿 C/C 双语言 API。本文以 doc/error_handling.md 为骨架结合仓库头文件与源码实现系统讲解 WARNING/ERROR 与异常的关系、rs2::error完整继承体系、C/C 跨界异常封送机制、回调与后台线程的错误传播约束以及设备热插拔、析构等边界场景下的错误语义帮助你写出健壮、可恢复的 RealSense 应用。总览为什么选择异常而非返回码librealsense 项目依赖基于异常的错误处理模型。与传统的返回码return-code方案相比该模型在接口设计上有着本质差异返回码模型要求调用方在每次调用后显式检查错误码遗漏检查即可能导致错误被静默吞掉异常模型则强制或引导调用方在合适的作用域内统一处理失败路径同时允许底层在抛出前保留失败的上下文函数名、参数、错误类型。用户在使用该库时可以安全地依赖以下三条后置条件post-conditions所有成功的操作在库内部都不会使用异常即只要 API 正常返回即可认为其内部没有发生被吞掉的异常如果 API 隐含了状态迁移state transition但调用因异常失败状态不会改变库会在需要时执行回滚调用失败不会留下半完成的状态只要摄像头保持连接所有合理的设备使用方式都应可以不依赖捕获异常来实现库始终提供能力动态发现dynamic discovery的 API——包括设备支持的方法、有效控制范围control ranges等让用户程序可以在运行期适配设备能力而不是靠异常来探路。这条设计哲学意味着异常应当被理解为程序假设被打破的信号而不是常规控制流的一部分。能力枚举类 API如查询 option 的min/max/default/step范围的完备性正是为了让正常流程无需依赖异常。错误、警告与异常WARNING / ERROR 的分级机制每当 librealsense 遇到一次系统调用system call失败时它会将其记录为一条WARNING或ERROR日志条目如何开启 librealsense 日志可参考 doc/troubleshooting.md如果问题在库内部可恢复则该事件被标记为WARNING如果问题需要用户介入则库会创建一个exception对象并同时写入一条ERROR日志。从源码实现看这一分级在异常类定义处即被固化src/librealsense-exception.h 中unrecoverable_exception的构造函数会直接调用LOG_ERROR(msg)而recoverable_exception则不强制记录日志由其派生类按需处理两种层级通过rs2_exception_type枚举定义于 include/librealsense2/h/rs_types.h携带错误类型信息。值得注意的另一个信息源是固件FW错误文档提示完整的固件错误列表可参考src/ds5/ds5-private.h当前仓库中相关头文件为 src/ds/advanced_mode 与 d400/d500 系列私有头如 src/ds/d400、src/ds/d500其中编码了设备侧可上报的具体硬件/固件错误码。后台线程错误转化为 rs_notification 而非异常异常并不总是抛给调用方。关键规则如下如果失败操作不是由用户发起而是由库的后台线程background threads执行则异常绝不应到达进程的全局信号处理器global signal handler。相反异常会被转换为rs_notification对象并通过**通知回调notifications callback**发送给用户。从源码看src/error-handling.cpp 中的polling_error_handler演示了这一机制它以可配置的轮询间隔poll_intervals_ms周期性查询设备侧的 last-error option一旦读取到非零错误值先尝试在固件侧复位错误标志再通过notifications_processor::raise_notification(...)将解码后的notification派发给已注册的回调。raise_notification的实际派发逻辑位于 src/rs.cpp它通过内部dispatcher异步调用_callback-on_notification(noti)——这种异步派发保证了回调不会阻塞错误轮询循环。用户的 C 程序通过传感器或设备的set_notifications_callback接口声明见 src/core/sensor-interface.h注册回调从而以事件驱动而非异常捕获的方式感知后台错误。用户发起操作rs_error 跨界封送机制如果操作由用户发起异常对象会在rs.cpp这一层被安全地**封送marshalled**到模块边界之外库内部抛出 C 异常如 src/librealsense-exception.h 中的camera_disconnected_exception、backend_exception、invalid_value_exception等rs.cpp中的 C API 入口通过BEGIN_API_CALL/HANDLE_EXCEPTIONS_AND_RETURN宏体系捕获异常并调用rs2_create_error将其转换为rs_error对象返回给调用方src/rs.cpp同时记录LOG_ERRORC 程序可以直接消费这个rs_error通过rs2_get_error_message、rs2_get_failed_function、rs2_get_failed_args等查询函数见 src/rs.cpp如果应用使用的是rs.hppC 包装则rs2::error::handle会将rs_error对象重新转换回异常对象抛出见 include/librealsense2/hpp/rs_types.hpp。最终抛出的这个异常无论原始异常类型如何必然同时派生自rs2::error和std::runtime_error。这一设计让 C 用户既可以按库定义的错误层级捕获也可以按标准库层级兜底。在 C API 侧错误类型通过rs2_get_librealsense_exception_type(const rs2_error* error)查询include/librealsense2/h/rs_types.h枚举定义如下typedef enum rs2_exception_type { RS2_EXCEPTION_TYPE_UNKNOWN, // 未知类型 RS2_EXCEPTION_TYPE_CAMERA_DISCONNECTED, // 设备已断开可能由外部干预、内部固件错误或供电不足导致 RS2_EXCEPTION_TYPE_BACKEND, // 底层 OS 特定层返回的错误 RS2_EXCEPTION_TYPE_INVALID_VALUE, // 传入 API 的值无效 RS2_EXCEPTION_TYPE_WRONG_API_CALL_SEQUENCE, // 函数前置条件被违反调用顺序错误 RS2_EXCEPTION_TYPE_NOT_IMPLEMENTED, // 方法尚未实现 RS2_EXCEPTION_TYPE_DEVICE_IN_RECOVERY_MODE, // 设备处于恢复模式可能需要固件更新 RS2_EXCEPTION_TYPE_IO, // IO 设备故障 RS2_EXCEPTION_TYPE_COUNT // 枚举数量仅用于 for 循环不是合法输入 } rs2_exception_type;错误类型体系rs2::error 的完整继承结构除字符串形式的错误描述外librealsense 异常还提供get_failed_function()与get_failed_args()分别查询失败的函数名与实参值并提供错误类型查询。rs.hpp会自动将错误类型映射为如下继承结构std::exception └── std::runtime_error └── rs2::error ├── rs2::unrecoverable_error | ├── rs2::camera_disconnected_error // 调用期间摄像头被断开 | ├── rs2::backend_error // 系统调用返回失败 | └── rs2::device_in_recovery_mode_error // 设备需要固件更新 └── rs2::recoverable_error ├── rs2::invalid_value_error // 传入 librealsense 的参数值无效 ├── rs2::wrong_api_call_sequence_error // API 前置条件未满足 └── rs2::not_implemented_error // 操作未实现或当前设备不支持该继承结构在 include/librealsense2/hpp/rs_types.hpp 中有完整的 C 实现rs2::error派生自std::runtime_error保存function、args与type三个成员随后通过RS2_ERROR_CLASS(name, base)宏依次生成recoverable_error、unrecoverable_error及其六个具体子类。error::handle依据rs2_get_librealsense_exception_type的返回值将 C 侧错误精确地重新抛为对应的 C 具体异常类型。与之一一对应的库内部异常类定义于 src/librealsense-exception.hcamera_disconnected_exception、linux_backend_exception/windows_backend_exception均派生自backend_exception、invalid_value_exception、wrong_api_call_sequence_exception、not_implemented_exception、io_exception等且各自绑定相应的RS2_EXCEPTION_TYPE_*枚举值。此外 src/error-handling.cpp 中还出现了RS2_NOTIFICATION_CATEGORY_HARDWARE_ERROR通知类别用于硬件错误类通知。约定如果用户捕获到的是笼统的rs2::error而非某个具体错误类这本身就可以视为一个 bug库侧的映射漏洞应当反馈给项目。正常路径下handle()总会抛出一个具体的子类。分层捕获的实战写法该继承结构让用户可以从最具体的错误向最一般的错误组织捕获代码try { dev.start(); } // 先写最具体的处理器 catch (const rs2::camera_disconnected_error e) { cerr Camera was disconnected! Please connect it back endl; // 等待 connect 事件设备重新插入 } // 再写更一般的处理器 catch (const rs2::recoverable_error e) { cerr Operation failed, please try again endl; } // 也可以捕获库抛出的任何其他错误 catch (const rs2::error e) { cerr Some other error occurred! endl; }捕获顺序建议与继承层级相反具体 → 一般。camera_disconnected_error属于unrecoverable_error分支代表设备级故障通常需要用户物理介入recoverable_error分支参数无效、调用顺序错误、未实现通常可以通过修正调用方式重试。各错误类型的使用语义与判定依据错误类型枚举值典型触发场景处理建议camera_disconnected_errorRS2_EXCEPTION_TYPE_CAMERA_DISCONNECTED调用期间设备被拔出、供电不足、固件内部错误提示用户重连等待设备变更事件后重建设备句柄backend_errorRS2_EXCEPTION_TYPE_BACKEND底层 UVC/USB 等系统调用返回失败如 Linux 上的ioctl错误记录errno等底层信息判断是否为可恢复的瞬时故障device_in_recovery_mode_errorRS2_EXCEPTION_TYPE_DEVICE_IN_RECOVERY_MODE设备处于恢复模式、固件损坏或需更新引导用户执行固件更新流程invalid_value_errorRS2_EXCEPTION_TYPE_INVALID_VALUE传入的参数值超出有效范围依据 option 的min/max/step动态查询合法值后重试wrong_api_call_sequence_errorRS2_EXCEPTION_TYPE_WRONG_API_CALL_SEQUENCE前置条件未满足如未 start 即 poll frame修正 API 调用顺序not_implemented_errorRS2_EXCEPTION_TYPE_NOT_IMPLEMENTED当前设备型号不支持该操作用能力发现 API 预先判断后再调用需要说明底层平台相关的错误如 Linux 后端会额外拼接strerror(errno)信息见 src/librealsense-exception.h 中linux_backend_exception::generate_last_error_message排查底层驱动问题时可直接从异常消息中读取系统错误码文本。两个重要边界设备断开与析构函数设备断开Disconnectslibrealsense2 提供了获取设备断开通知并从中恢复的机制但必须明确在物理断开发生之后、通知送达之前任何发起的操作都必然失败。rsutil2.hpp为处理设备断开提供了便捷类包括查询设备是否仍然连接的方法——实践中应优先使用该查询 API 判断设备状态而不是依赖捕获camera_disconnected_error之后的补救动作。典型的健壮模式是通过设备变更回调devices-changed callback感知设备移除/添加在每次操作前查询设备连接状态操作失败并抛出camera_disconnected_error时走提示用户重连 等待设备事件的恢复路径。析构函数Destructors唯一一种异常会被库内部消化而不通知用户的情况是对象销毁流程的一部分。例如device对象销毁时可能因设备已断开而触发系统调用失败。这类错误只会被记录到日志中而不会抛给用户——这是为了规避throw-in-destructor析构函数中抛异常导致std::terminate问题。因此用户在编写自己的 RAII 清理代码时也应遵守同样原则析构路径上的错误只记录、不抛出。回调中的异常不可传播、只记日志当前设计中没有任何机制能把用户回调内部抛出的异常传播回库中。如果用户回调抛出了异常该事件只会被记录到日志中等级为ERROR。这一约束对两类回调都适用帧回调frame callback在帧到达回调中抛出异常不会被库感知可能导致帧丢失且难以排查通知回调notifications callback库通过dispatcher异步调用src/rs.cpp回调内的异常同样无法回传。因此用户代码应在回调边界内自行try/catch兜底将回调视为库 → 用户单向事件通道切勿依赖回调向外抛出异常来传递错误。从错误处理到工程实践要点清单结合 doc/error_handling.md 与源码实现编写健壮的 librealsense 应用时建议遵循正常流程不依赖异常利用 option 范围查询、能力发现等 API见 include/librealsense2/hpp/rs_types.hpp 及rs2_options相关接口提前规避参数错误按具体 → 一般分层捕获先捕获rs2::camera_disconnected_error等具体异常再捕获recoverable_error最后用rs2::error兜底若捕获到裸rs2::error应视为库的 bug 反馈上游后台错误走通知回调为设备/传感器注册set_notifications_callback接收rs_notification形式的硬件错误与固件错误事件回调内自兜底用户回调中自行处理异常避免抛出到库内析构路径不抛出清理代码只记录错误不抛异常热插拔场景结合设备变更回调 连接状态查询 API正确处理物理断开与通知送达之间的失败窗口排查底层错误backend_error消息中通常携带strerror(errno)文本结合日志doc/troubleshooting.md定位驱动或系统调用层问题失败后状态可信任何抛出异常的失败调用都保证不会留下半迁移状态可安全地在修正输入后重试。如需实际演练可参考仓库中基于 rs.hpp 编写的示例程序如 examples/capture/rs-capture.cpp、examples/save-to-disk/rs-save-to-disk.cpp观察真实 API 调用方式与错误处理配合的完整模式。【免费下载链接】librealsenseRealSense SDK项目地址: https://gitcode.com/GitHub_Trending/li/librealsense创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 librealsense 错误处理方案完全指南：从异常模型到实战捕获策略
librealsense 错误处理方案完全指南从异常模型到实战捕获策略【免费下载链接】librealsenseRealSense SDK项目地址: https://gitcode.com/GitHub_Trending/li/librealsenselibrealsenseRealSense SDK以基于异常的exception-based错误处理作为核心设计贯穿 C/C 双语言 API。本文以 doc/error_handling.md 为骨架结合仓库头文件与源码实现系统讲解 WARNING/ERROR 与异常的关系、rs2::error完整继承体系、C/C 跨界异常封送机制、回调与后台线程的错误传播约束以及设备热插拔、析构等边界场景下的错误语义帮助你写出健壮、可恢复的 RealSense 应用。总览为什么选择异常而非返回码librealsense 项目依赖基于异常的错误处理模型。与传统的返回码return-code方案相比该模型在接口设计上有着本质差异返回码模型要求调用方在每次调用后显式检查错误码遗漏检查即可能导致错误被静默吞掉异常模型则强制或引导调用方在合适的作用域内统一处理失败路径同时允许底层在抛出前保留失败的上下文函数名、参数、错误类型。用户在使用该库时可以安全地依赖以下三条后置条件post-conditions所有成功的操作在库内部都不会使用异常即只要 API 正常返回即可认为其内部没有发生被吞掉的异常如果 API 隐含了状态迁移state transition但调用因异常失败状态不会改变库会在需要时执行回滚调用失败不会留下半完成的状态只要摄像头保持连接所有合理的设备使用方式都应可以不依赖捕获异常来实现库始终提供能力动态发现dynamic discovery的 API——包括设备支持的方法、有效控制范围control ranges等让用户程序可以在运行期适配设备能力而不是靠异常来探路。这条设计哲学意味着异常应当被理解为程序假设被打破的信号而不是常规控制流的一部分。能力枚举类 API如查询 option 的min/max/default/step范围的完备性正是为了让正常流程无需依赖异常。错误、警告与异常WARNING / ERROR 的分级机制每当 librealsense 遇到一次系统调用system call失败时它会将其记录为一条WARNING或ERROR日志条目如何开启 librealsense 日志可参考 doc/troubleshooting.md如果问题在库内部可恢复则该事件被标记为WARNING如果问题需要用户介入则库会创建一个exception对象并同时写入一条ERROR日志。从源码实现看这一分级在异常类定义处即被固化src/librealsense-exception.h 中unrecoverable_exception的构造函数会直接调用LOG_ERROR(msg)而recoverable_exception则不强制记录日志由其派生类按需处理两种层级通过rs2_exception_type枚举定义于 include/librealsense2/h/rs_types.h携带错误类型信息。值得注意的另一个信息源是固件FW错误文档提示完整的固件错误列表可参考src/ds5/ds5-private.h当前仓库中相关头文件为 src/ds/advanced_mode 与 d400/d500 系列私有头如 src/ds/d400、src/ds/d500其中编码了设备侧可上报的具体硬件/固件错误码。后台线程错误转化为 rs_notification 而非异常异常并不总是抛给调用方。关键规则如下如果失败操作不是由用户发起而是由库的后台线程background threads执行则异常绝不应到达进程的全局信号处理器global signal handler。相反异常会被转换为rs_notification对象并通过**通知回调notifications callback**发送给用户。从源码看src/error-handling.cpp 中的polling_error_handler演示了这一机制它以可配置的轮询间隔poll_intervals_ms周期性查询设备侧的 last-error option一旦读取到非零错误值先尝试在固件侧复位错误标志再通过notifications_processor::raise_notification(...)将解码后的notification派发给已注册的回调。raise_notification的实际派发逻辑位于 src/rs.cpp它通过内部dispatcher异步调用_callback-on_notification(noti)——这种异步派发保证了回调不会阻塞错误轮询循环。用户的 C 程序通过传感器或设备的set_notifications_callback接口声明见 src/core/sensor-interface.h注册回调从而以事件驱动而非异常捕获的方式感知后台错误。用户发起操作rs_error 跨界封送机制如果操作由用户发起异常对象会在rs.cpp这一层被安全地**封送marshalled**到模块边界之外库内部抛出 C 异常如 src/librealsense-exception.h 中的camera_disconnected_exception、backend_exception、invalid_value_exception等rs.cpp中的 C API 入口通过BEGIN_API_CALL/HANDLE_EXCEPTIONS_AND_RETURN宏体系捕获异常并调用rs2_create_error将其转换为rs_error对象返回给调用方src/rs.cpp同时记录LOG_ERRORC 程序可以直接消费这个rs_error通过rs2_get_error_message、rs2_get_failed_function、rs2_get_failed_args等查询函数见 src/rs.cpp如果应用使用的是rs.hppC 包装则rs2::error::handle会将rs_error对象重新转换回异常对象抛出见 include/librealsense2/hpp/rs_types.hpp。最终抛出的这个异常无论原始异常类型如何必然同时派生自rs2::error和std::runtime_error。这一设计让 C 用户既可以按库定义的错误层级捕获也可以按标准库层级兜底。在 C API 侧错误类型通过rs2_get_librealsense_exception_type(const rs2_error* error)查询include/librealsense2/h/rs_types.h枚举定义如下typedef enum rs2_exception_type { RS2_EXCEPTION_TYPE_UNKNOWN, // 未知类型 RS2_EXCEPTION_TYPE_CAMERA_DISCONNECTED, // 设备已断开可能由外部干预、内部固件错误或供电不足导致 RS2_EXCEPTION_TYPE_BACKEND, // 底层 OS 特定层返回的错误 RS2_EXCEPTION_TYPE_INVALID_VALUE, // 传入 API 的值无效 RS2_EXCEPTION_TYPE_WRONG_API_CALL_SEQUENCE, // 函数前置条件被违反调用顺序错误 RS2_EXCEPTION_TYPE_NOT_IMPLEMENTED, // 方法尚未实现 RS2_EXCEPTION_TYPE_DEVICE_IN_RECOVERY_MODE, // 设备处于恢复模式可能需要固件更新 RS2_EXCEPTION_TYPE_IO, // IO 设备故障 RS2_EXCEPTION_TYPE_COUNT // 枚举数量仅用于 for 循环不是合法输入 } rs2_exception_type;错误类型体系rs2::error 的完整继承结构除字符串形式的错误描述外librealsense 异常还提供get_failed_function()与get_failed_args()分别查询失败的函数名与实参值并提供错误类型查询。rs.hpp会自动将错误类型映射为如下继承结构std::exception └── std::runtime_error └── rs2::error ├── rs2::unrecoverable_error | ├── rs2::camera_disconnected_error // 调用期间摄像头被断开 | ├── rs2::backend_error // 系统调用返回失败 | └── rs2::device_in_recovery_mode_error // 设备需要固件更新 └── rs2::recoverable_error ├── rs2::invalid_value_error // 传入 librealsense 的参数值无效 ├── rs2::wrong_api_call_sequence_error // API 前置条件未满足 └── rs2::not_implemented_error // 操作未实现或当前设备不支持该继承结构在 include/librealsense2/hpp/rs_types.hpp 中有完整的 C 实现rs2::error派生自std::runtime_error保存function、args与type三个成员随后通过RS2_ERROR_CLASS(name, base)宏依次生成recoverable_error、unrecoverable_error及其六个具体子类。error::handle依据rs2_get_librealsense_exception_type的返回值将 C 侧错误精确地重新抛为对应的 C 具体异常类型。与之一一对应的库内部异常类定义于 src/librealsense-exception.hcamera_disconnected_exception、linux_backend_exception/windows_backend_exception均派生自backend_exception、invalid_value_exception、wrong_api_call_sequence_exception、not_implemented_exception、io_exception等且各自绑定相应的RS2_EXCEPTION_TYPE_*枚举值。此外 src/error-handling.cpp 中还出现了RS2_NOTIFICATION_CATEGORY_HARDWARE_ERROR通知类别用于硬件错误类通知。约定如果用户捕获到的是笼统的rs2::error而非某个具体错误类这本身就可以视为一个 bug库侧的映射漏洞应当反馈给项目。正常路径下handle()总会抛出一个具体的子类。分层捕获的实战写法该继承结构让用户可以从最具体的错误向最一般的错误组织捕获代码try { dev.start(); } // 先写最具体的处理器 catch (const rs2::camera_disconnected_error e) { cerr Camera was disconnected! Please connect it back endl; // 等待 connect 事件设备重新插入 } // 再写更一般的处理器 catch (const rs2::recoverable_error e) { cerr Operation failed, please try again endl; } // 也可以捕获库抛出的任何其他错误 catch (const rs2::error e) { cerr Some other error occurred! endl; }捕获顺序建议与继承层级相反具体 → 一般。camera_disconnected_error属于unrecoverable_error分支代表设备级故障通常需要用户物理介入recoverable_error分支参数无效、调用顺序错误、未实现通常可以通过修正调用方式重试。各错误类型的使用语义与判定依据错误类型枚举值典型触发场景处理建议camera_disconnected_errorRS2_EXCEPTION_TYPE_CAMERA_DISCONNECTED调用期间设备被拔出、供电不足、固件内部错误提示用户重连等待设备变更事件后重建设备句柄backend_errorRS2_EXCEPTION_TYPE_BACKEND底层 UVC/USB 等系统调用返回失败如 Linux 上的ioctl错误记录errno等底层信息判断是否为可恢复的瞬时故障device_in_recovery_mode_errorRS2_EXCEPTION_TYPE_DEVICE_IN_RECOVERY_MODE设备处于恢复模式、固件损坏或需更新引导用户执行固件更新流程invalid_value_errorRS2_EXCEPTION_TYPE_INVALID_VALUE传入的参数值超出有效范围依据 option 的min/max/step动态查询合法值后重试wrong_api_call_sequence_errorRS2_EXCEPTION_TYPE_WRONG_API_CALL_SEQUENCE前置条件未满足如未 start 即 poll frame修正 API 调用顺序not_implemented_errorRS2_EXCEPTION_TYPE_NOT_IMPLEMENTED当前设备型号不支持该操作用能力发现 API 预先判断后再调用需要说明底层平台相关的错误如 Linux 后端会额外拼接strerror(errno)信息见 src/librealsense-exception.h 中linux_backend_exception::generate_last_error_message排查底层驱动问题时可直接从异常消息中读取系统错误码文本。两个重要边界设备断开与析构函数设备断开Disconnectslibrealsense2 提供了获取设备断开通知并从中恢复的机制但必须明确在物理断开发生之后、通知送达之前任何发起的操作都必然失败。rsutil2.hpp为处理设备断开提供了便捷类包括查询设备是否仍然连接的方法——实践中应优先使用该查询 API 判断设备状态而不是依赖捕获camera_disconnected_error之后的补救动作。典型的健壮模式是通过设备变更回调devices-changed callback感知设备移除/添加在每次操作前查询设备连接状态操作失败并抛出camera_disconnected_error时走提示用户重连 等待设备事件的恢复路径。析构函数Destructors唯一一种异常会被库内部消化而不通知用户的情况是对象销毁流程的一部分。例如device对象销毁时可能因设备已断开而触发系统调用失败。这类错误只会被记录到日志中而不会抛给用户——这是为了规避throw-in-destructor析构函数中抛异常导致std::terminate问题。因此用户在编写自己的 RAII 清理代码时也应遵守同样原则析构路径上的错误只记录、不抛出。回调中的异常不可传播、只记日志当前设计中没有任何机制能把用户回调内部抛出的异常传播回库中。如果用户回调抛出了异常该事件只会被记录到日志中等级为ERROR。这一约束对两类回调都适用帧回调frame callback在帧到达回调中抛出异常不会被库感知可能导致帧丢失且难以排查通知回调notifications callback库通过dispatcher异步调用src/rs.cpp回调内的异常同样无法回传。因此用户代码应在回调边界内自行try/catch兜底将回调视为库 → 用户单向事件通道切勿依赖回调向外抛出异常来传递错误。从错误处理到工程实践要点清单结合 doc/error_handling.md 与源码实现编写健壮的 librealsense 应用时建议遵循正常流程不依赖异常利用 option 范围查询、能力发现等 API见 include/librealsense2/hpp/rs_types.hpp 及rs2_options相关接口提前规避参数错误按具体 → 一般分层捕获先捕获rs2::camera_disconnected_error等具体异常再捕获recoverable_error最后用rs2::error兜底若捕获到裸rs2::error应视为库的 bug 反馈上游后台错误走通知回调为设备/传感器注册set_notifications_callback接收rs_notification形式的硬件错误与固件错误事件回调内自兜底用户回调中自行处理异常避免抛出到库内析构路径不抛出清理代码只记录错误不抛异常热插拔场景结合设备变更回调 连接状态查询 API正确处理物理断开与通知送达之间的失败窗口排查底层错误backend_error消息中通常携带strerror(errno)文本结合日志doc/troubleshooting.md定位驱动或系统调用层问题失败后状态可信任何抛出异常的失败调用都保证不会留下半迁移状态可安全地在修正输入后重试。如需实际演练可参考仓库中基于 rs.hpp 编写的示例程序如 examples/capture/rs-capture.cpp、examples/save-to-disk/rs-save-to-disk.cpp观察真实 API 调用方式与错误处理配合的完整模式。【免费下载链接】librealsenseRealSense SDK项目地址: https://gitcode.com/GitHub_Trending/li/librealsense创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考