【问题标题】:Where to use exception handling在哪里使用异常处理
【发布时间】:2019-06-04 02:37:00
【问题描述】:

我有一个使用支付服务类的 MVC 控制器。我应该在哪里进行异常处理?什么是最佳实践?

我是否在我的控制器和服务类中都使用 try/catch 块? 是否只是在服务类中再次抛出异常,以便可以在控制器中处理?还是应该在控制器中完成所有异常处理? 我可以捕获 Stripe 特定的异常,应该在服务类或控制器中完成吗?迷茫……

public async Task<IActionResult> DoSomething(MyViewModel model)
{    
    try
    {
        await _paymentService.UpdateSomethingAsync(id, token);
    }
    catch (Exception ex)
    {
        //handle
    }
    enter code here    
}

public class PaymentService : IPaymentService
{   
    public async Task UpdateSomethingAsync(string id, string token)
    {
        try
        {
            //update using Stripe...
        }
        catch (Exception ex)
        {
            //TODO: Implement error handling
            throw;
        }
    }
}

【问题讨论】:

  • 这个问题太宽泛了,不能简单地回答。这里要考虑的因素太多了,不可能将它们全部放在一个简短的答案中。相反,请查看文档:docs.microsoft.com/dotnet/csharp/programming-guide/exceptions/…
  • 通常情况下,uncauthexception(动作)过滤器用于记录异常。
  • 好的,考虑到我有一个使用 Stripe 的支付服务。我是否应该在我的支付服务中捕获异常并再次抛出。或者我可以在控制器中捕获。即在支付服务中没有尝试/捕获,只是在控制器中?
  • 我认为您的案例的策略取决于您想要完成的例外情况以及您希望如何返回响应客户端。如果您需要特别记录任何不一定会影响对用户的响应的内容,我认为您可以在服务本身内执行此操作,然后将其抛出以被外部捕获。然后在外部捕获添加/格式化您需要在那里记录的信息并向客户端返回适当的响应。请注意,封装在 try-catch 和日志记录中会影响性能,因此正如 @HimBromBeere 所说,对此没有简单的答案。
  • 一般来说,如果你打算用它做某事,你只会捕获一个异常,并且你会在你打算采取行动的地方捕获它。牢记这两条简单的规则,您将很快找到捕获任何特定异常的正确位置。

标签: c# asp.net-mvc exception-handling


【解决方案1】:

只需在 catch 中编写与 try{ } 中相同的代码,因为 catch 永远不会传回或返回值。

   try
        {
            cust_id = txtID.Text;
            submit changes();
            lblmessage.Text = "Data Save";
        }
        catch (Exception ex)
        {
              lblmessage.Text = "Saving error";
              cust_id = txtID.Text;
              submit changes();

        }

【讨论】:

    【解决方案2】:

    我猜异常处理必须在服务级别,因为它应该能够自行捕获和处理所有发生在服务级别的异常(也可以在服务级别记录以供以后分析)并以其原始形式抛出(或者根据需要可以在服务级别定制)到接收器。

    接收器(在这种情况下为控制器)应该有自己的错误处理机制,因为它是应用程序的不同层,可能需要对异常进行一些操作,或者它在 UI 级别进行日志记录。这里请注意,如果不需要操作或记录异常或错误,您可以直接显示服务级别异常并从控制器中删除 catch。

    希望它有意义。

    【讨论】:

      猜你喜欢
      • 2011-03-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-03-27
      • 2012-05-22
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多