使用消息类静态方法接受操作来包装 Try/Catch

Question

我有一个 Result 对象，它允许我传递事件消息列表，并且我可以检查操作是否成功。

我意识到我已经在很多地方编写了这段代码

Result result;

try
{
    //Do Something 
    ...

    //New result is automatically a success for not having any errors in it
    result = new Result(); 
}
catch (Exception exception)
{
    //Extension method that returns a Result from the exception
    result = exception.ToResult();
}

if(result.Success) ....

我正在考虑将这种用法替换为

public static Result CatchException(Action action)
{
    try
    {
        action();
        return new Result();
    }
    catch (Exception exception)
    {
        return exception.ToResult();
    }
}

然后使用它就像

var result = Result.CatchException(() => _model.Save(something));

有人觉得这有什么问题或者我正在用可重用性换取晦涩难懂吗？

编辑：我捕获所有异常的原因是我在与模型交互的任何时候都在 ViewPresenter 类中使用此代码，因为如果我收到未处理的异常，我宁愿将实际错误显示给用户（内部应用程序），而不是仅仅将他们重定向到通用错误页面。

Answer 1

我认为使用函数式方法并传入 lambda 没有任何问题。这是完全正确的。

话虽这么说，我会质疑你在这个特定场景中的使用。将所有异常捕获到通用“Result”类中似乎很危险。理想情况下，您应该捕获可以正确处理的异常 - 不是所有可能的异常并继续。

话虽这么说，如果你真的想这样做，我有几个建议给你：

1）我会为成功创建一个静态的、不可变的结果，然后这样做：

result = result.Success;

这可以避免每次你生成一个新的“成功”。成功，这希望是最常见的选择。

2）我可能会避免使用扩展方法，并且这样做：

result = new Result(exception);

这在意图上会更加清晰和明显，并且在这种情况下确实没有理由执行扩展方法......

Answer 2

您不应该像这样捕获Exception。您应该只捕获您知道如何处理的已知异常类型。

如果这样做，您的代码将不再如此重复，因此就没有必要使用此模式来实现可重用性。

总的来说，这看起来是一个非常糟糕的主意，不仅仅是 lambda 模式，我正在谈论通过将异常转换为结果对象来处理异常。您基本上是在允许自己忽略所有异常并继续工作。 C# 错误处理使用异常而不是返回代码是有原因的，这是因为异常允许结构化、分层和基于调用堆栈的处理。除非您简化了这个问题的代码，否则我会重新考虑您的异常处理过程。

---

但总的来说，我认为 lambda 模式没有任何问题。我自己使用类似的方法来包装代码块的多次重试。但在这种情况下，我认为这不是你所需要的。

Answer 3

如果您觉得需要编写这样一个自动异常处理程序系统，您可能会过度使用异常，这可能会产生严重的性能影响。

然而，这似乎是一个将异常转换为错误代码的通用系统 - 那么为什么不首先使用错误代码呢？或者学习更有效地使用异常，这样您就不需要将它们转换为错误代码？事实上，你试图将它们转换成其他东西，这应该引起你的警惕，并表明你在某个地方错过了重点。