【发布时间】:2014-10-30 01:33:47
【问题描述】:
Qt 是not currently exception safe,似乎也不是ever likely to be。这对与 Qt 交互的 C++ 代码有什么限制?
如果我想使用 Qt,我是否需要在我的代码中避免所有 C++ 异常?
【问题讨论】:
Qt 是not currently exception safe,似乎也不是ever likely to be。这对与 Qt 交互的 C++ 代码有什么限制?
如果我想使用 Qt,我是否需要在我的代码中避免所有 C++ 异常?
【问题讨论】:
您可以对要在应用程序中使用的任何其他非异常安全库执行相同的两件事:将其隔离在异常安全包装器中,或放弃异常并适应其风格。你真正要问的是第一个是否可行。
对于您的字面问题,您绝对不需要避免所有例外情况。所有返回错误代码的 Qt 函数、不能正确清理自身的类等都可以很容易地封装起来。而且你没有充分的理由在 Qt 上抛出异常,所以你不能抛出异常也没关系。而且您通常不会将 Qt 对象传递给依赖于异常的非 Qt 库。等等。最棘手的是它会考虑如何编写,例如,如果真正的构造函数以无效值成功,则将销毁并抛出 QImage 包装器,这并不难。
但最大的问题是您不能通过信号槽连接抛出异常。如果你想以典型的方式组织你的代码,其中低级函数抛出大部分异常,而顶级函数完成大部分异常处理,但你想使用 Qt 作为你的大部分中间层,那可能不是会很愉快。*例如,对于传统的重型控制器 MVC 设计,其中大部分控制器都构建在 Qt 上,您对异常的使用最终将非常本地化,并且没有那么有用。另一方面,对于 MVA 设计或智能模型设计,您的大部分逻辑可能根本不直接处理 Qt,因此您仍然可以在相当大的范围内遇到异常。 (当然,这是假设您在不必要的地方不使用 Qt。)
* 即使在这里,也可能把事情总结一下。例如,您不能抛出线程连接、条件等待等,但您可以构建以干净方式在线程之间传递异常的期货和执行器。使用相同类型的脚手架,您可以通过槽传递异常。但这是相当繁重的脚手架,你最终会得到一个与典型 Qt 程序完全不同的 API,所以它似乎不值得。
【讨论】: