【问题标题】:Handling OnError events in a class library在类库中处理 OnError 事件
【发布时间】:2011-11-27 17:47:24
【问题描述】:

我正在编写一个包装不同对象的类库 (主要是 USB 硬件组件的设备驱动程序)

这些设备驱动程序的某些类公开了“OnError”类型的事件:简而言之,如果设备驱动程序中发生运行时错误或其他错误,则触发该事件。比如:

    AddHandler oDevice.DriverRunTimeErrorEvent, 
               AddressOf HandleDriverRunTimeErrorEvent

    Private Sub HandleDriverRunTimeErrorEvent(
                ByVal sender As Object,
                ByVal eventData As DriverRunTimeErrorEventArgs)
        'handle the error
    End Sub

这个解决方案的好处是,如果发生错误,程序不会停止,但如果我不使用事件,我永远不知道会发生什么。

现在,将设备驱动程序包装到我的类库中,我必须考虑我必须传递给将使用我的类库的客户端的内容以及是否应该这样做。

  1. 我可以转发设备驱动程序解决方案并在类库中生成一个新事件。然后客户端应该处理转发的事件。

  2. 但我也可以抛出包含所有错误信息的异常

  3. 我可以简单地忽略该错误并将其记录在协议文件中。

解决方案 1. 对我来说似乎更强大,我会使用它,但它与 .NET 世界并不“接近”。

解决方案 2. 与程序流异步抛出错误:在客户端应用程序中,我不会有任何可能捕获它的 try-catch 块。换句话说,该类可能会在客户端没有调用该类的任何方法的情况下引发错误。 当然,我可以在应用程序级别捕获所有错误,但无论如何这会在逻辑中引入一些我希望避免的模糊性。

您将如何处理这些 OnError 事件?

【问题讨论】:

标签: .net visual-studio exception exception-handling


【解决方案1】:

错误事件是应用程序逻辑。我不明白您为什么要在库中处理这些事件。

【讨论】:

  • 如果我不处理错误事件,那么使用我的类库的客户端将永远无法获得有关设备驱动程序中任何此类错误的信息。
【解决方案2】:

您应该始终执行选项 3,与您选择向用户显示错误的方法无关 - 当然,如果它可以合理实现,即如果您对存储空间足够大以保存日志具有写访问权限。

在 1 和 2 之间进行选择取决于您选择的向用户提供错误信息的一般方法。在 .NET 世界中,抛出异常是首选,至少在标准情况下是这样,而且我的标准是指如果您的接口是同步的。如果您的用户正在调用您的类的方法并等待您返回一个值(或只是完成执行) - 那么如果出现“足够”的错误,您应该抛出异常

在某些情况下,您可能需要避免引发异常,其中之一是您提供给客户端的接口是异步的。如果他们调用您的方法并且您立即返回,则将工作线程留在后台 - 然后抛出异常根本不是一种选择,您需要添加类似的基于事件的方法来让您的客户订阅错误信息 - 如果他们需要它!这是您需要决定的事情(除非您发布有关项目性质的更多详细信息) - 如果您只需将错误记录到文件中就可以逃脱,那么为什么还要麻烦引发事件?

您可能需要实施不基于异常的错误通知还有另一个原因。您可能仍然有一个同步模型 - 客户端调用您并等待您的操作完成 - 然后您可以(并且您应该)使用事件来通知调用者操作无法成功结束。但是您可能会区分“足够错误”和“轻微错误”。考虑以下场景:

客户端调用一个方法,你开始一个异步操作,但在某个时候开始等待它完成,例如与Thread.JoinWaitHandle.WaitOne。当工作线程最终完成时,您将结果返回给用户。您可以从底层框架订阅错误事件 - 但您可以将此错误标识为非致命错误,因此您可以决定继续等待后台线程完成而不是抛出异常,但无论如何都会通知用户该错误(再一次——只有在你需要的时候,你通常可以通过简单的记录来逃脱)。您可以通过事件或返回值(或ref/out 参数)来执行此操作。后者是更主流的方法 - 您只需返回一个非致命错误列表,在大多数情况下它将是空的,如果客户关心 - 他会检查列表。

差不多就是这样,它主要取决于您的类库的接口 - 是否同步,如果您分享更多详细信息,您可以获得更具体的答案。

【讨论】:

    猜你喜欢
    • 2011-01-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-02-28
    • 1970-01-01
    • 1970-01-01
    • 2019-03-30
    • 1970-01-01
    相关资源
    最近更新 更多