c# - 如何设计流畅的界面(用于异常处理)？

Question

我正在审查代码库的一部分，我来到异常处理部分，这真的很乱。我想用更优雅的东西代替它。然后我想如果我可以有一个流畅的界面来帮助我为异常列表注册一些策略，然后让 ExceptionHandlingManager 为我做剩下的事情，这可能不是一个坏主意:

这是一个它应该如何工作的例子:

For<TException>.RegisterPolicy<TPolicy>(a lambda expression that describes the detail);

但我完全迷路了。我在正确的轨道上吗？当我们想要设计这样一个流畅的界面时，最好的方法是什么？我的意思是，如果流畅的界面是 DSL 的一部分，那么设计流畅的界面就像设计语言一样吗？

---

我正在谈论的这个模块是一个通用模块，负责所有未处理的异常。它是一个像这样的一百行模块:

if(exp.GetType()==typeof(expType1))
{
    if(exp.Message.Include("something went bad"))
    // do list of things things like perform logging to database 
    // and translating/reporting it to user
}
else if (exp.GetType()==typeof(expType2))
{
    //do some other list of things...
    ...
}

Answer 1

这是我第二次尝试回答您的问题。据我正确理解，您正试图从这样的代码中摆脱嵌套的 ifs 和 elses:

if(exp.GetType()==typeof(expType1))
{
    if(exp.Message.Include("something went bad"))
    {
      if(exp.InnerException.Message == "Something inside went bad as well";
      {
        DoX();
        DoY();
      }
    }
}
else if (exp.GetType()==typeof(expType2))
{
  DoZ();
  DoV();
}

现在考虑您已经创建了一个如下所示的链式 API:

var handlingManager = new ExceptionHandlingManager();
handlingManager
 .For<Exception>()
   .HavingAMessage(message => message.Includes("something went bad"))
   .WithInnerException<SomeInnerException>()
     .HavingAMessage(innerMessage => innerMessage == "Something inside went bad as well")
   .Perform(() => 
   {
     DoX();
     DoY();
   });

甚至是这样的:

var handlingManager = new ExceptionHandlingManager();
handlingManager
 .For<Exception>()
   .HavingAMessageThatIncludes("something went bad")
   .WithInnerException<SomeInnerException>()
     .HavingAMessageEqualTo("Something inside went bad as well")
   .Perform(() => 
   {
     DoX();
     DoY();
   });

这两者实际上并不能给您带来任何好处。让我们快速列举嵌入式领域特定语言的两个特性:

1. 它们将您使用的操作集限制为仅与域关联的操作集
2. 它们提供了更具表现力的 API，比通用语言更能描述问题。

现在，重要的是，如果您创建了一种语言来根据某些对象属性设置操作(就像我上面给您的两个示例)，它会满足第 1 点，但不会满足第 2 点。如果您将“流畅”版本与“普通 C#”版本进行比较，“普通 C# 版本”实际上更具表现力(字符更少)和可读性更强(我已经知道 C#，但我还不知道你的 API)，即使“流利”版本更冗长(但 DSL 和流利界面与冗长无关，它们与表达能力和可读性有关)。

换句话说，“流利”版本对我的期望更高(学习新的 API)，同时没有提供任何优势(“流利”API 并不比普通的 C# 更具表现力)，这让我永远不想甚至尝试“流利”版本。

另外，你说你想摆脱嵌套的 ifs。为什么会这样？在许多嵌入式 DSL 中，我们努力嵌套在它能更好地反射(reflect)解决方案结构的地方(参见 http://broadcast.oreilly.com/2010/10/understanding-c-simple-linq-to.html 中的第一个示例 - 它是用于编写 XML 的 Microsoft 嵌入式 DSL)。另外，请看一下我的两个示例 - 我故意设置间距是为了向您展示当您切换到 dotted().notation() 时嵌套并没有真正消失。

还有一点。 “流利”版本可能会给您一种错觉，即通过使用规则预先配置一个对象，它会在需要时执行这些规则，从而使您变得更加“声明性”，但这实际上与采用“普通 C#”版本并将其放入分离对象或方法并在需要时调用该方法。可维护性完全相同(实际上，“纯 C#”版本可能更易于维护，因为使用“流畅”版本，每次遇到尚未处理的情况时，您都必须使用新方法扩展 API通过 API)。

所以，我的结论是:如果你需要一个通用的 DSL 来基于一些对象比较来触发操作，那么停止 - C# 及其“if”、“else”、“try”和“catch”语句是已经擅长于此，而使其“流利”的 yield 是一种幻想。领域特定语言用于将领域特定的操作包装在富有表现力的 API 后面，而您的情况看起来不像。

如果您真的想摆脱嵌套的 ifs，那么一个更好的主意是更改抛出逻辑以根据异常类型而不是异常属性来区分失败场景。例如。而不是:

if(situationA)
{
  throw Exception("XYZ");
}
else if (situationB)
{
  throw Exception("CVZF");
}

做到:

if(situationA)
{
  throw ExceptionXYZ();
}
else if (situationB)
{
  throw ExceptionCVZF();
}

那么您将不需要嵌套的 ifs - 您的异常处理将是:

try
{
  XYZ()
}
catch(ExceptionXYZ)
{
  DoX();
  DoY();
}
catch(ExceptionCVZF)
{
  DoZ();
  DoV();
}