8

在我们的 WF4 工作流服务中，我们尝试尽可能地健壮。我们要做的一件事是在 HandleError 和 ProvideFault ( IErrorhandler ) 中记录错误。文档清楚地指出 HandleError 将是进行日志记录的正确位置，但我看到发生了一些奇怪的事情：

  1. 我看到一些仅触发ProvideFault的错误，但从未触发 HandleError，一个示例是：

    System.NullReferenceException：对象引用未设置为对象的实例。在 System.ServiceModel.Activities.Dispatcher.DurableInstanceManager.GetInstanceAsyncResult.GetInstance() 在 System.ServiceModel.Activities.Dispatcher.DurableInstanceManager.GetInstanceAsyncResult..ctor

  2. 还有一些错误只会触发HandleError，但不会触发 ProvideFault，一个例子是：

    System.ServiceModel.CommunicationException：从管道读取错误：管道已结束。(109, 0x6d)。在 System.ServiceModel.Channels.PipeConnection.Read(Byte[] 缓冲区，Int32 偏移量，Int32 大小，TimeSpan 超时) 在 System.ServiceModel.Channels.SessionConnectionReader.Receive(TimeSpan 超时)

  3. 最后有触发两者的错误，首先是ProvideFault，然后是HandleError（在后台线程上）

  4. 如果可能的话，我也想记录相应的传入消息。我使用OperationContext.Current.RequestContext.RequestMessage.ToString()执行此操作这通常仅适用于 ProvideFault，在 HandleError 中我们不再有 RequestContext

所以我的结论是，要记录所有错误，我必须同时登录这两种方法。但这会导致大量重复的日志条目，因为 3..

我当前的解决方法是“记住”来自 ProvideFault 的最后记录的异常，如果相同的异常进入 HandleError，则忽略它。在我看来不是很干净。

有没有人更好、更可靠的方法来记录WF 服务中可能发生的所有错误？

请不要使用 HandleError 或 ProvideFault 中的 IErrorHandler 在 WCF 中记录异常？因为那没有提供任何帮助。

4

1 回答 1

0

我已经看到场景 2 发生在不同的上下文（BizTalk 适配器）中，它似乎HandleError被调用是因为适配器中发生了异常，但没有ProvideFault被调用，因为没有实际返回的消息 - 故障发生在这样的防止适配器实际生成/读取/翻译消息并将其传递到管道的方式。这似乎甚至阻止了生成错误消息。从管道读取失败似乎构成了这一点 - 您的服务不知道它是否失败，因为它甚至从未连接过，或者它是否因为远程服务器失败而失败。诸如此类的事情也可能导致这种情况，或者（在我的特定情况下）a可能导致这种情况。TransactionAbortedExceptionSqlException

这应该为案例 #1 提供一些线索，我自己没有看到或复制过它：这是由于消息链中某处的异常处理不当造成的。在这种情况下，生成了一条错误消息，但链上的某些东西未能以HandleError可以调用的方式处理异常。ANullReferenceException在这里是有道理的——如果你没有正确处理空检查，很难说在这种情况下还会发生什么。

就解决这个问题而言，我可能会尝试在这两个地方登录，并提供一些额外的信息来解释日志的来源。这将是故障安全的，即使它确实重复记录。另一方面，如果你有一个生成这些场景中的一个或两个的异常列表，你可以实现逻辑来检查它是什么类型的异常（或它发生在哪里）——如果它是一个异常，可能会减少日志记录很可能通过其他方法处理。

于 2016-01-26T23:36:44.330 回答