Question

在编写代码时，我发现我的代码看起来很好很重要（除了它必须工作之外）。 Code Complete（p729）一书中对此进行了详细描述：'格式良好的代码的视觉和智能享受是一种乐趣，很少有非程序员能够欣赏'。

问题是，只要我的代码功能正常工作，并且我开始引入错误处理（try-except子句等）以使其健壮，我发现这通常会弄乱我精心设计的代码并把它变成一种绝对不会令人愉悦的东西。 try-except语句和其他if语句使代码的可读性和结构性降低。

我想知道这是因为我滥用或过度使用错误处理，还是这是不可避免的？有什么提示或技巧可以保持好看吗？

Answer 1

很难给出一个通用的答案，因为有很多不同的错误处理案例，所以有很多不同的方法来处理这个问题。如果你要发布一些真实的例子，你可能会在这里得到很多关于如何改进代码的建议。

通常，将错误处理添加到现有函数会使它们更大，因此将它们重构为更小的方法总是一个好主意。如果您正在寻找更通用的方法，那么您应该对Aspect-Oriented programming感到满意。这是一种方法，可以完全排除业务逻辑代码中所谓的交叉问题（如错误处理）的代码。

编辑：只是一个简单的伎俩：

我避免像这样编写错误检查：

 int MyFunction()
 {
    if( ErrorCheck1Passes())
    {
       if( ErrorCheck2Passes())
       {
           if( ErrorCheck3Passes())
           {
                callSomeFunction(...);
           }
           else
              return failureCode3;
        }
        else
           return failureCode2;
    }
    else
       return failureCode1;

    return 0;
 }

我更喜欢

int MyFunction()
{
   if( !ErrorCheck1Passes())
       return failureCode1;
   if( !ErrorCheck2Passes())
       return failureCode2;
   if( !ErrorCheck3Passes())
       return failureCode3;

   callSomeFunction(...);
   return 0;
}

Answer 2

我经常将需要错误处理的代码块包装到他们自己的函数中，这些函数将在内部处理所有可能的异常，因此在某种意义上总是成功。调用它们的代码看起来更干净，如果多次调用这些函数，那么代码也会变小。

如果您在应用程序的前端工作更多，这可能更有意义，从用户的角度来看，并非每个可能的异常都需要冒泡到他们的级别。在某些类的上下文中，它可以很好地处理错误并继续前进。

例如，我可能有像

这样的函数

SaveSettingsSafe();
// 'Safe' in the sense that all errors are handled internally before returning

Answer 3

你重新发现了Don Knuth发明literate programming的一个主要原因：错误处理常常掩盖主算法。如果你很幸运，你会有一些语言结构为你提供一些灵活性。例如，异常可能允许您将错误处理移动到其他位置，或者第一类函数可以移动错误处理并减少if-then-else检查函数调用。

如果您遇到没有这些功能的语言（如C语言），您可能需要研究一种有文化的编程工具。 Literate编程工具是预处理器，但它们的全部任务是帮助您使代码更具可读性。他们有一个小但狂热的追随者，你将能够在网上和已发表的论文中找到一些指导。

Answer 4

这一切都取决于你的编程方式。如果您只是进行适当的输入验证，则可以避免使用这些try-catch（或者当您放置try-except）语句。当然，要覆盖大多数垃圾用户倾向于放入表单等方面需要做很多工作，但它会使您的数据处理例程保持干净（或者更清洁）。

如何在引入错误处理时保持代码布局在视觉上“有吸引力”？

4 个答案: