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