我正在编写一个包装不同对象的类库 （主要是USB硬件组件的设备驱动程序）
这些设备驱动程序的某些类暴露了类型为“OnError”的事件：简而言之，如果设备驱动程序中发生运行时错误或其他错误，则会触发该事件。类似的东西：
AddHandler oDevice.DriverRunTimeErrorEvent,
AddressOf HandleDriverRunTimeErrorEvent
Private Sub HandleDriverRunTimeErrorEvent(
ByVal sender As Object,
ByVal eventData As DriverRunTimeErrorEventArgs)
'handle the error
End Sub
这个解决方案的正面是如果发生错误，程序不会停止，但如果我不使用该事件，我将永远不会知道发生了什么。
现在，将设备驱动程序包装在我的类库中，我必须考虑我必须传递给将使用我的类库的客户端，如果我应该这样做。
我可以转发设备驱动程序解决方案并在类库中生成一个新事件。然后客户端应该处理转发的事件。
但我也可以使用所有错误信息抛出异常
我可以简单地忽略错误，只需将其记录在协议文件中即可。
解决方案1.对我来说似乎更健壮，我会使用它，但它并不“接近”.NET世界。
解决方案2.与程序流异步抛出错误：在客户端应用程序中，我没有任何可以捕获它的try-catch块。换句话说，如果客户端没有调用该类的任何方法，则该类可能会抛出错误。 当然，我可以在应用程序级别捕获所有错误，但无论如何，这会在我希望避免的逻辑中引入一些模糊性。
您将如何处理这些OnError事件？
答案 0 :(得分：1)
选项3你应该总是这样做，独立于你向用户提供错误的方法选择 - 当然，如果它是合理可行的，即你有足够大的存储写入权限来保存日志。
在1和2之间选择取决于您选择向用户提供错误信息的一般方法。在.NET世界中，抛出异常是首选，至少在标准情况下是这样，而标准我指的是你的接口是同步的。如果您的用户正在调用您的类的方法并等待您返回一个值（或者只是完成执行） - 那么如果出现错误“足够”，您应该抛出异常
在某些情况下，您可能需要避免抛出异常，例如，如果您提供给客户端的接口是异步的。如果他们调用你的方法并立即返回，在后台留下一个工作线程 - 然后抛出异常根本不是一个选项，你需要添加一个类似的基于事件的方法让你的客户订阅错误信息 - 如果他们需要它！这是您需要决定的事情（除非您发布有关项目性质的更多详细信息） - 如果您只是将错误记录到文件中，那么为什么还要提起事件？
还有另一个原因可能是您需要实现不基于异常的错误通知。您可能仍然有一个同步模型 - 客户端呼叫您并等待您的操作完成 - 然后您可以（并且您应该）使用事件来通知呼叫者该操作无法成功结束。但是你可能会区分“错误”和“轻度错误”。请考虑以下情形：
客户端调用方法，启动异步操作，但在某些时候开始等待它完成，例如使用Thread.Join或WaitHandle.WaitOne。当工作线程最终完成时，将结果返回给用户。您可以从底层框架订阅错误事件 - 但是您可以将此错误识别为非致命错误，因此您可以决定继续等待后台线程完成，而不是抛出异常，但无论如何都要通知用户错误（再次 - 只有你需要，通常只需记录即可逃脱）。您可以通过事件或返回值（或ref / out参数）来执行此操作。后者是更主流的方法 - 你只返回一个非致命错误列表，在大多数情况下会是空的，如果客户关心 - 他会查看列表。
这就是它，它主要取决于你的类库的界面 - 它是否同步，如果你分享更多细节，你可以得到更具体的答案。
答案 1 :(得分：0)
错误事件是应用程序逻辑。我不明白你为什么要在库中处理这些事件。