代码之家 › 专栏 › 技术社区 › Mark Rushakoff

catch语句与代码行的良好比率[关闭]

code-smell try-catch c#

Mark Rushakoff · 技术社区 · 15 年前

对于在一个大的软件中,每个源代码行预期有多少catch语句,有什么经验法则吗?

例如,在用C语言编写的一个软件中,Visual Studio显示了大约350行,其中包含“catch”一词,以及 cloc 报告称,我们有大约160k条sloc、30k条评论行和15k条空白行。160K/350大约是每个catch语句467行代码。

但是用一点盐来说明这一点,因为我们使用标准的C格式,在它们自己的行上加上大括号,所以谁知道有多少行只是160K中的单个大括号,而160K正在计算树中某些不再编译到应用程序中的文件,等等。我可能猜测“有用”比率接近于每400个loc一个catch。

至少我并不惊讶,我们遗漏了一个半关键的异常,这个异常正被捕获在一个空的catch块中,所以现在我将遍历代码库,至少将该异常作为临时措施打印到调试控制台,或者对捕获的异常更加具体。这当然会增加我们在整个应用程序中的捕获数,但它会使我们更接近“可接受”区域吗?我不知道每467个地点一次抓获是好的,只是好的,甚至是可怕的。

我很清楚 为什么? 不要使用空的catch块。其他/以前的维护人员都很懒惰。由于本产品的下一个版本是时间关键型的,所以我目前没有时间进入并正确地修复所有300(?)糟糕的catch语句和验证软件的正确操作(当然,我们实际上没有自动化测试来简化这一过程:/)。

我只是在寻找是否有什么“直觉”,关于一个人应该多久看一次尝试捕捉。有几个答案说它是上下文敏感的,这是我怀疑的,但我不确定。

4 回复 | 直到 15 年前

Jon Skeet 15 年前

很难给出一个大概的数字——它将真正取决于应用程序要做什么,以及它是否需要执行那些可能以可恢复的方式失败的操作。

重要的一点是,空的捕获块是一个非常非常糟糕的主意。这比每个catch块的代码行更重要。

John Saunders 15 年前

除非你真的打算手柄他们。除非处理程序能够“撤消”异常,或者以其他方式添加值,否则应该允许异常冒泡到那些可以处理它。

Reed Copsey 15 年前

我会完全忽略任何这样的指标。计算代码行数不一定是有用的指标——尤其是在寻找比率时。

这里真正的答案完全取决于上下文。catch语句的“正确”数量是处理可能发生的异常所需的try/catch块的数量,您将正确处理这些异常。对于任何可能发生的、您可以正确处理的异常,您应该有一个try/catch块。如果你不能正确地处理它(或者不想正确地处理它),就让它向上传播——不要抓住它。

catch块的数量将完全取决于您正在编写的代码类型。例如,如果您正在编写网络代码,您将更有可能拥有更多的异常处理(因为从本质上讲,网络更可能具有需要处理的问题)。

Austin Salonen gmlacrosse 15 年前

作为一个非常粗略的度量标准,我的经验法则是在每个事件处理程序中至少有一个将记录异常。

对于其他方法,我更喜欢让它们尝试释放catch;也就是说,我多次添加catch块以将状态添加到麻烦的错误报告(“参数=值”),然后“抛出”到主处理程序。如果你擅长修复bug,这种方法会导致很多死代码。