Question

研究.net中的一些异常处理功能，并希望了解处理未知异常的最佳实践。

场景：在服务层，我拥有如下最重要的功能。使用从异常和异常派生的catch语句，这是否有效？

public CalcResponse DoSomething(int a, int b){
  var calcResponse = new CalcResponse();
  try 
   {
      var calcService = service.EvaluateSomething(a,b);
      calcResponse.Result  = calcService.Result;
   }
   catch(ArgumentNullException exc){
     //log and return meaningful error message, below is just an example.
     calcResponse.Result = "Invalid Numbers, try again";
   }
   catch(Exception e)
   {
     //log and return meaningful error message, below is just an example.
     calcResponse.Result = "Please try again...";
   }
}

所以我有argumentNullexception和其他异常处理程序，我认为可以发生并专门处理它们。对于未知异常，可以是我处理的任何其他内容，并且不想将有关我的服务的任何信息发送给客户端，我声明了catch（异常e）。捕获（例外e），在最顶层是一个好习惯吗？

注意：该服务正在处理并仅抛出派生的异常。

更新我的问题更多的是处理顶级异常，而不是以正确的方式通知客户。我将尝试基于技术堆栈（如rest或wcf）进行通知。

在最高级别的不良做法中有Catch（例外e）吗？

Answer 1

在上面的示例中，您正在捕捉异常并返回“请再试一次”。有了这些，您将永远无法识别代码中的问题，因为您永远不会看到您的错误冒出来。您的客户会说“我收到了错误”，但该错误将永远不会出现在您的错误日志中，因此您不知道出了什么问题。这是不使用try / catch块的主要原因。

try / catch块在正确的上下文中非常有用，但这里有几个原因可以避免它们：

他们很贵
他们隐藏您的错误

最好在代码的UI层上捕获参数null问题。让您的服务层免费开展业务逻辑。

我建议您查看Elmah，这是一种记录错误的免费方式。

Answer 2

对我来说，您正在实施第二次错误处理。作为您服务的潜在用户，这很糟糕。

我必须实施异常处理，因为有无数的事情可能会出错，无法联系您的服务。

现在，我必须实现一组if / else条件，因为你选择以不同的方式返回错误。

请不要这样做。有一种叫做Faults的简单机制。故障被转换为（和来自）.NET异常。不要添加与标准不兼容的错误层。

如果您想控制服务报告的错误（例如您不想提供实施细节），那很好。抓住它们并抛出特定于您的服务的异常。但要坚持使用经过验证的机制并抛出异常和/或错误。 不要介绍您自己的返回代码。你的来电者需要两倍的工作，你什么也得不到。

.net服务层中异常处理的最佳实践

2 个答案: