抛出Win32Exception
我最近编写了很多涉及与Win32 API互操作的代码，并开始想知道什么是处理由Windows API函数调用引起的本机（非托管）错误的最佳方法。
目前，对本机函数的调用如下所示：
// NativeFunction returns true when successful and false when an error // occurred. When an error occurs, the MSDN docs usually tell you that the // error code can be discovered by calling GetLastError (as long as the // SetLastError flag has been set in the DllImport attribute). // Marshal.GetLastWin32Error is the equivalent managed function, it seems. if (!WinApi.NativeFunction(param1, param2, param3)) throw new Win32Exception(); 引发exception的行可以等效地重写，我相信：
throw new Win32Exception(Marshal.GetLastWin32Error());
现在，这一切都很好，因为它会抛出一个exception，其中包含设置的Win32错误代码以及作为Exception对象的Message属性的（通常）人类可读的错误描述。 但是，我一直在考虑修改/包装至少一些（如果不是全部）这些exception是明智的，这样它们会给出一个稍微更多的面向上下的错误消息，即在本机代码的任何情况下都更有意义。正在使用。 我考虑了几个替代方案：
-
在
Win32Exception的构造函数中指定自定义错误消息。throw new Win32Exception(Marshal.GetLastWin32Error(), "My custom error message."); -
将
Win32Exception包装在另一个Exception对象中，以便保留原始错误代码和消息（Win32Exception现在是父exception的InnerException）。throw new Exception("My custom error message.", Win32Exception(Marshal.GetLastWin32Error())); -
与2相同，除了使用另一个
Win32Exception作为包装器exception。 -
与2相同，除了使用从
Exception派生的自定义类作为包装器exception。 -
与2相同，除了在适当时使用BCL（基类库）exception作为父类。 在这种情况下，不确定它是否适合将
InnerException设置为Win32Exception（可能对于低级包装器而不是更高级/抽象的接口，这并不能说明Win32互操作在幕后发生？）
基本上我想知道的是：在.NET中处理Win32错误的推荐做法是什么？ 我看到它以各种不同的方式在开源代码中完成，但我很好奇是否有任何设计指南。 如果没有，我会对您的个人偏好感兴趣。 （也许你甚至不使用上述方法？）
这并不是特定于Win32exception; 问题是，何时应该由两个不同的Exception派生类型识别两个不同的错误情况，何时它们应该抛出存储在其中的不同值的相同类型？
不幸的是，如果事先不知道你的代码将被调用的所有情况，这是不可能回答的。:)这是只能按类型过滤exception的问题。 从广义上讲，如果您有强烈的感觉，以不同的方式处理两个错误情况会有用，请抛出不同的类型。
否则，通常情况是Exception.Message返回的字符串只需要记录或显示给用户。
如果有其他信息，请使用更高级别的内容包装Win32Exception。 例如，您正在尝试对文件执行某些操作，而您正在运行的用户无权执行此操作。 捕获Win32Exception，将其包装在您自己的exception类中，其消息提供文件名和正在尝试的操作，然后是内部exception的消息。
我的观点一直是，处理这个问题的适当方法取决于目标受众以及您的课程将如何使用。
如果你的类/方法的调用者要意识到他们以某种forms调用Win32，我会使用你指定的选项1）。 这对我来说似乎是最“清晰”的。 （但是，如果是这种情况，我会以明确表示将直接使用Win32 API的方式命名您的类）。 话虽如此，BCL中有一些例外，实际上将Win32Exception的子类更加清晰，而不是仅仅包装它。 例如，SocketException派生自Win32Exception。 我从来没有亲自使用过这种方法，但它看起来似乎是一种处理这种方法的潜在干净方法。
如果你的类的调用者不知道你直接调用Win32 API，我会处理exception，并使用你定义的自定义，更具描述性的exception。 例如，如果我正在使用你的类，并且没有迹象表明你正在使用Win32 api（因为你在内部使用它是出于某些特定的，非显而易见的原因），我没有理由怀疑我可能需要处理Win32Exception。 你可以随时记录这一点，但是对我来说似乎更合理的是捕获它并给出一个在你的特定业务环境中具有更多意义的exception。 在这种情况下，我可能将初始Win32Exception包装为内部exception（即：您的案例4），但是根据导致内部exception的原因，我可能不会。
此外，很多时候从本机调用中抛出Win32Exception，但BCL中还有其他更相关的例外。 当您调用未包装的本机API时会出现这种情况，但是在BCL中包含了类似的函数。 在那种情况下，我可能会捕获exception，确保它是我所期待的，但随后抛出标准的BCLexception。 一个很好的例子是使用SecurityException而不是抛出Win32Exception。
但一般来说，我会避免你列出的选项2和3。
选项二抛出一般的exception类型 – 我非常建议完全避免这种情况。 将特定exception包装成更广义的exception似乎是不合理的。
选项三似乎是多余的 – 与选项1相比确实没有优势。
我个人会做＃2或＃4 …最好是＃4。 在您的exception中包装Win32Exception，这是对上下文敏感的。 像这样：
void ReadFile() { if (!WinApi.NativeFunction(param1, param2, param3)) throw MyReadFileException("Couldn't read file", new Win32Exception()); }
这样，如果有人捕获exception，他们就会很好地了解问题发生的位置。 我不会做＃1因为它需要catch来解释你的文本错误信息。 并且＃3并没有真正提供任何其他信息。