处理WCF服务错误的最佳实践
本文关键字：最佳 错误 WCF 服务 处理 | 更新日期: 2023-09-27 18:01:38
我正在编写某种WCF服务。大多数异常都在BL实现中捕获并在那里处理。我的每个API的返回类型都是一个类(命名为- "result")，包含错误代码，错误消息和成功布尔值。
当异常被处理时，这个类被相应地更新，最后被发送回客户端。一些例外情况偏离了轨道，没有得到处理。目前，我正在用一个通用的try-catch来包装来自服务层的每个BL调用，这样我就可以捕获每个未处理的异常，并创建一个通用的"结果"类，其中包含通用的失败消息、错误代码和success=false。
这是一个处理异常的好方法，还是我应该让未处理的异常由服务抛出给客户端?您可以假设客户端不能使用异常中的数据，因此它不会从异常中包含的额外信息中获益。
检查异常屏蔽。
在这个过程中，服务引发的异常，根据您在配置文件中指定的规则映射到错误契约。这节省了大量使用try/catch块的繁琐工作。
这里有一篇文章可以帮助你:
一般来说，故障可分为3类:
1)客户端错误-客户端试图做一些不允许的事情，所以它需要知道它。设置必填字段失败。—返回详细的故障解释信息
2)不影响客户端的业务错误。被认为是正常操作的错误，例如付款授权检查失败。要么完全隐藏客户端，要么返回一些消息:"执行请求错误:请稍后再试…"
3)系统错误-意外-不正常操作:替换为通用消息:"System error: Call Support"
在所有情况下，关键的事情是你删除堆栈跟踪，特别是如果它是一个面向公众的服务。
有了屏蔽，你将有3个包含上述场景的故障合同，并在屏蔽配置中设置适当的文本。
请注意，您通常希望在开发期间关闭屏蔽，因为它使调试系统变得非常痛苦!
我和其他人不一样。我认为，以同样的方式，HTTP方法GET, POST, PUT, DELETE因此支持CRUD操作，HTTP响应代码200,500等，支持成功/失败，在我看来，这是适当的使用。500结果仍然有HTTP响应体，并且这样的响应体是完全可读的(只要IIS不输出HTML;你可以控制这个)。同时，XML协议实现(如WCF中的Microsoft SOAP)已经用错误协议包装了异常。
如果你要抛出异常，那就抛出。在这样做的同时记录它们，以便消费者可以相应地进行计划。
我认为两种方法都是可行的。
我个人不喜欢在WCF上抛出异常，这样客户端可以很容易地区分服务器端处理中的错误和连接/协议问题:在第一种情况下，响应将表明失败，在第二种情况下，将抛出异常。
我个人不会公开未处理的异常并将它们传播给客户机。我将定义客户机可能感兴趣的异常，并只传播这些异常。与客户端想要做的事情没有直接关系的异常(ArgumentException可以将原因设置为"CustomerId不能超过20个字符"等)，我将在服务中处理，只表明服务端发生了某种内部服务器错误，破坏了执行，意味着客户端试图运行的操作未能完成。我会这样做，因为客户端无法真正根据内部服务器错误采取任何行动。在抛出ArgumentException的情况下，它们可以通过再次验证参数并重试操作来修复它们的inparams。
不确定这是不是你想要的，但希望它至少能给你一些想法。
如果您让未处理的异常离开WCF服务，这可能会产生不良影响，例如通信通道处于故障状态，在会话场景中，客户端不能再使用相同的客户端代理实例，而是被迫创建一个新实例并启动一个新会话。一般来说，我认为最好控制WCF服务中出现的错误，并向客户提供有用的信息。看一下IErrorHandler。该接口使您能够控制生成的SOAP错误和未处理的异常，并允许您执行额外的任务，如日志记录，并允许您决定在会话绑定的情况下是否要保留会话。您可以通过WCF可扩展性添加自定义错误处理程序，例如服务、端点、契约、操作行为。
注意IErrorHandler在发送响应消息之前被调用。因此，在序列化、编码等过程中，仍然有可能在通道堆栈中发生未处理的异常。