抛出 Win32Exception

Question

我最近编写了大量涉及与 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();

引发异常的行可以等效地重写为这样我相信：

throw new Win32Exception(Marshal.GetLastWin32Error());

现在，这一切都很好，因为它抛出了一个适当包含已设置的 Win32 错误代码的异常作为（通常）人类可读的错误描述，作为 Exception 对象的 Message 属性。 但是，我一直在认为，建议至少修改/包装这些异常中的一些（如果不是全部），以便它们给出稍微更面向上下文的错误消息，即在本机代码的任何情况下都更有意义正在使用。 我已经考虑了几种替代方案：

1. 在 Win32Exception 的构造函数中指定自定义错误消息。

throw new Win32Exception(Marshal.GetLastWin32Error(), "My custom error message.");

2. 将 Win32Exception 包装在另一个 Exception 对象中，以便保留原始错误代码和消息（Win32Exception 现在是父异常的 InnerException ）。

throw new Exception("My custom error message.",
        Win32Exception(Marshal.GetLastWin32Error()));

3. 与 2 相同，只是使用另一个 Win32Exception 作为包装异常。

4. 与 2 相同，只是使用从 Exception 派生的自定义类作为包装异常。

5. 与 2 相同，只是在适当的时候使用 BCL（基类库）异常作为父异常。 不确定在这种情况下将 InnerException 设置为 Win32Exception 是否合适（可能适用于低级包装器，但不适用于不支持的高级/抽象接口）难道Win32互操作是在幕后发生的吗？）

本质上我想知道的是：处理 .NET 中的 Win32 错误的推荐做法是什么？ 我看到它以各种不同的方式在开源代码中完成，但我很好奇是否有任何设计指南。 如果没有，我会对您的个人喜好感兴趣。 （或许以上方法你都没有使用过？）

Answer 1

这并不是真正特定于 Win32 异常； 问题是，什么时候应该由两个不同的 Exception 派生类型来标识两个不同的错误情况，以及它们什么时候应该抛出内部存储有不同值的相同类型？

不幸的是，如果不事先知道代码将被调用的所有情况，这是不可能回答的。:) 这是只能按类型过滤异常的问题。 一般来说，如果您强烈认为以不同的方式处理两个错误情况会很有用，请抛出不同的类型。

否则，经常出现的情况是 Exception.Message 返回的字符串只需要记录或显示给用户。

如果有其他信息，请用您自己的更高级别的内容包装 Win32Exception。 例如，您正在尝试对文件执行某些操作，而您运行的用户没有执行此操作的权限。 捕获 Win32Exception，将其包装在您自己的异常类中，其消息给出文件名和正在尝试的操作，后跟内部异常的消息。

Answer 2

我的观点始终是，处理此问题的适当方法取决于目标受众以及您的课程将如何使用。

如果您的类/方法的调用者意识到他们正在以一种或另一种形式调用 Win32，我将使用您指定的选项 1)。 这对我来说似乎是最“清楚”的。 （但是，如果是这种情况，我会以明确将直接使用 Win32 API 的方式命名您的类）。 话虽这么说，为了更清楚，BCL 中的一些异常实际上是 Win32Exception 的子类，而不是仅仅包装它。 例如，SocketException 派生自 Win32Exception。 我个人从未使用过这种方法，但它似乎确实是处理此问题的一种潜在的干净方法。

如果类的调用者不知道您直接调用 Win32 API，我将处理该异常，并使用您定义的自定义的、更具描述性的异常。 例如，如果我正在使用您的类，并且没有迹象表明您正在使用 Win32 api（因为您出于某些特定的、非显而易见的原因在内部使用它），那么我没有理由怀疑我可能需要处理 Win32Exception。 您始终可以记录这一点，但对我来说，捕获它并给出一个在您的特定业务环境中更有意义的例外似乎更合理。 在这种情况下，我可能会将初始的 Win32Exception 包装为内部异常（即：您的情况 4），但根据导致内部异常的原因，我可能不会。

此外，很多时候本机调用会引发 Win32Exception，但 BCL 中还有其他更相关的异常。 当您调用未包装的本机 API，但 BCL 中包装了类似的函数时，就会出现这种情况。 在这种情况下，我可能会捕获该异常，确保它是我所期望的，然后在其位置抛出标准的 BCL 异常。 一个很好的例子是使用 SecurityException 而不是抛出 Win32Exception。

但总的来说，我会避免您列出的选项 2 和 3。

选项二抛出一般异常类型 - 我强烈建议完全避免这种情况。 将特定的异常包装成更通用的异常似乎是不合理的。

选项三似乎多余——与选项一相比确实没有优势。

Answer 3

就我个人而言，我会做#2或#4......最好是#4。 将 Win32Exception 包装在上下文相关的异常中。 像这样：

void ReadFile()
{
    if (!WinApi.NativeFunction(param1, param2, param3))
        throw MyReadFileException("Couldn't read file", new Win32Exception());
}

这样，如果有人捕获异常，他们就会很清楚问题发生在哪里。 我不会做＃1，因为它需要捕获来解释您的文本错误消息。 #3 并没有真正提供任何额外的信息。