在dll边界上抛出c ++异常是好的 [英] Is throwing c++ exceptions across dll boundaries good

问题描述

您好，

我正在编写C ++ dll，它将被第三方应用程序使用。其中一个构造函数初始化一些可能导致异常的数据。



我的问题是，我应该将此异常抛给调用应用程序处理和显示消息吗？它是否会导致跨应用程序的编译器依赖性问题？



请建议最好的方法来处理这种情况。



Gajesh



我尝试了什么：



我可以进行初始化在一个单独的函数中构造函数的一部分，但这会给最终用户带来额外的负担，我想避免。

Hello,
I am writing C++ dll which is going to be consumed by 3rd party application. One of it's constructor initializes some data which may cause exception.

My question is, should I throw this exception to calling application for handling and display message? Will it cause any compiler dependency issues across application?

Please suggest best way to handle this scenario.

Gajesh

What I have tried:

I can take initialization part out of constructor in a separate function but this will give addition burden on end user which I want to avoid.

推荐答案

这不好。当DLL可能抛出execptions时，使用它的所有模块必须链接到相同的C ++运行时。甚至可能需要使用相同的编译器版本，但我不确定这一点。



当使用特定构造函数的DLL内的所有函数返回状态时，您可以通过在初始化失败时设置内部错误状态来省略调用其他初始化函数。除了检查应该完成的返回值之外，这将不会增加额外的负担。

It is not good. When the DLL may throw execptions, all modules using it must be linked against the same C++ runtime. It may be even necessary to use the same compiler version but I'm not sure about this.

When all functions inside the DLL using the specific constructor return a status, you might omit calling an additional initialisation function by setting an internal error state when the initialisation fails. This will add no additional burden except checking return values which should be done anyway.

我的第一个使用DLL与C ++的规则是不。底部通常比它的价值更痛苦。



如果我不能遵循我的第一条规则我的第二条规则是不给DLL一个C ++接口，只需使用普通的C接口。这意味着对通过接口传递的对象使用不透明指针，基本类型和POD结构，也不会传播异常。



如果你不能按照我的第三条规则第二个规则是为客户提供源代码，以便他们可以使用构建应用程序的编译器编译自己的代码版本。如果你这样做，你可以在接口上做任何你想做的事情，因为你知道但是编译器实现名称修改，异常传播和进程堆它都会工作。



有一些方法可以在DLL之间使用一些C ++构造。作为一个例子，Windows的大多数编译器使用兼容的v表（如果它们没有，COM将无法工作），因此您可以通过接口将指针传递给接口类，并期望即使您使用不同也可以正确调用它们具有不同名称修改方法的编译器。这些技术是否值得做，取决于你愿意容忍的语言去除程度。

My first rule of using DLLs with C++ is don't. It's generally more pain in the bottom than it's worth.

If I can't follow my first rule my second rule is don't give a DLL a C++ interface, just use a plain C interface instead. This means use opaque pointers, primitive types and POD structures for objects passed across the interface and don't propagate exceptions either.

My third rule if you can't follow the second rule is give clients the source code so they can compile their own version of the code with the compiler they build their applications with. If you do this you can do whatever you want at the interface as you know that however the compiler implements name mangling, exception propagation and the process heap it'll all work.

There's some ways you can use some C++ constructs between DLLs. As an example most compilers for Windows use compatible v-tables (COM wouldn't work if they didn't) so you might be able to pass pointers to interface classes across the interface and expect them to be called properly even if you use different compilers with different methods of name mangling. Whether these techniques are worth doing depends on how much emasculation of the language you're willing to tolerate.

这篇关于在dll边界上抛出c ++异常是好的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！