引发异常时，在Delphi 2010/2009中内置的Dll与Delphi 7不兼容 [英] Dll built in Delphi 2010/2009 not compatible to Delphi 7 when an Exception is raised

问题描述

我已在Delphi 2010中构建了一个dll，并且已在我的delphi 7应用程序中使用。

我知道unicode AnsiString /字符串问题，根据我的测试，直到我的delphi 2010 dll没有引发异常时，一切正常。 / p>

事实是，是否存在任何与unicode / AnsiString世界兼容的特殊/已处理异常？也就是说，我的Delphi 2010是否能够引发可以在我的delphi 7应用程序中适当处理的异常？

寻求帮助。

Danilo。

解决方案

看到梅森（Mason）和耶隆（Jeroen）都提示我，这是：
（Jeroen，请不要丢下您的点，您也有有效的分数）。

Jeroen指出，没有一种语言可以跨dll边界。在一定程度上，我同意。它取决于dll的预期用途，尤其是涉及诸如字符串之类的语言特定功能时。如果您开发的DLL将仅与Delphi项目一起使用，尤其是当仅与您自己的Delphi项目一起使用时，则没有理由为了避免字符串越过边界而惹恼PChar等。

所以即使异常是特定于语言的，对我而言，这也不是不允许异常转义dll的主要原因。也不存在由于它们的语言特殊性而无法在dll之外处理它们的事实。

不允许异常转义dll的基本原因是相同的至于不允许异常转义线程：清理自己的混乱。另外：转义一个线程的异常会使您的应用崩溃。对于转义dll的异常而言，情况可能并非如此，但dll –一个甚至比线程还多的自包含实体，应与调用它的人无关，并且包括与呼叫者处理不可预见的情况，即例外。

那么，如何确保dll不会在调用者的整个聚会上践踏呢？我猜有很多通往罗马的道路，但我认为最简单的是OLE所做的事情：

• 每个导出方法应该返回一个代码，该代码告诉调用方是否一切正常，或者出了什么问题。




• 在返回代码中具体说明。不仅要报告出问题，还要为所有阻止该方法完成其工作的代码编写代码。像DLL_OK，DLL_OUT_OF_MEMORY，DLL_FILE_NOT_FOUND，DLL_INVALID_XXX（用于报告无效的输入参数）等代码也是如此。




• 在调用dll的应用程序中，对通用DLL_Check进行编码函数来检查返回代码并引发适当的异常，其余代码可以视情况处理这些异常。




• 使用特定的异常类来执行此操作。也就是说，对于需要处理的特定情况，一般的EDllError异常类及其各种后代。这对E ...编码以外的其他项目有很大帮助。




• 因为方法的返回值用于确定/错误报告：在需要返回有意义值的方法中使用out或var参数。




• 有关OLE拖放的msdn文档，以获取特定返回码的示例以及如何使用var和out参数与调用方交换信息的示例。

  
  

链接：

• 数据传输入口点： http://msdn.microsoft。 com / zh-CN / library / ms680067（v = VS.85）.aspx




• DoDragDrop函数： http://msdn.microsoft.com/zh-CN/library/ms678486（ v = VS.85）.aspx

I've built a dll in Delphi 2010 and it's consumed in my delphi 7 application.

I'm aware of the unicode AnsiString / string matter and according to my tests everything works fine up to the moment that no exception is raised by my delphi 2010 dll.

The fact is, is there any special/treated exception that is compatible to the unicode/AnsiString world? That is, is my Delphi 2010 able to raise an exception that can be handled appropriately in my delphi 7 app?

thanx for any help.

Danilo.

解决方案

Seeing as both Mason and Jeroen prompted me, here goes: (Jeroen, don't drop yours, you have valid points as well).

Jeroen states that nothing language specific should cross a dll boundary. Up to a point I agree. It depends on the intended use of the dll, especially when it comes to such language specific features as string. If you develop a dll that is going to be used exclusively with Delphi projects, and especially when that is only with your own Delphi projects, there is no reason to mess with PChar's and the like just to avoid strings crossing the boundary.

So even though exceptions are language specific, to me that is not the main reason for not allowing exceptions to escape the dll. Nor the fact that because of their language specificity it could be impossible to handle them outside of the dll.

The basic reasons for not allowing exceptions to escape a dll are the same as for not allowing exceptions to escape a thread: clean up your own mess. Plus: an exception escaping a thread will bring your app come crashing down. That may not be the case for an exception escaping a dll, but a dll - even more than a thread should be a self-contained entity, independent of who is calling it and that includes being independent of the caller in handling unforeseen circumstances, ie exceptions.

So how do you ensure that a dll does not trample all over the caller's party? I guess there are many roads that lead to Rome, but the simplest to my mind is what OLE does:

• Every exported method should return a code which tells the caller if everything was fine, or if something went wrong.

• Be specific in return codes. Don't just report something went wrong, have a code for everything that stops the method from doing what it was called to do. So have codes like DLL_OK, DLL_OUT_OF_MEMORY, DLL_FILE_NOT_FOUND, DLL_INVALID_XXX (for reporting invalid input parameters), etc.

• In the app calling the dll, code a general DLL_Check function to check the return codes and raise appropriate exceptions that the rest of your code can handle as it sees fit.

• Use specific exception classes to do this. Ie a general EDllError exception class and various descendants thereof for specific situations you need to handle. This aids greatly in the except on E... do coding.

• Because the return value of a method is used for ok/error reporting: use out or var parameters in methods that need to return meaningful values.

• Check the msdn documentation on OLE drag drop for examples of specific return codes and how to use var and out parameters to exchange information with the caller.

Links:

• Data transfer entry point: http://msdn.microsoft.com/en-us/library/ms680067(v=VS.85).aspx

• DoDragDrop function: http://msdn.microsoft.com/en-us/library/ms678486(v=VS.85).aspx

这篇关于引发异常时，在Delphi 2010/2009中内置的Dll与Delphi 7不兼容的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！