Question

你认为抓住一个例外并重新抛出它是一个好习惯吗？

基本上我有一段代码，其中使用带有3个参数的构造函数创建颜色。并且颜色构造函数可能会抛出异常。

    public PointExtend(double x, double y, int r, int g, int b)
        : base(x, y)
    {
        try
        {
            var color = new Color(r, g, b);
            Color = color;                
        }
        catch (InvalidColorValueException)
        {
            throw;
        }
    }

Resharper说，抓住条款是多余的，我同意，考虑到我没有对Exception做任何事情，但又扔了它，如果我不这样做，它会泄漏到UI，但不是。这个代码让程序员更容易阅读，所以如果他创建了PointExtend，他会知道代码可能会抛出什么？

Answer 1

除非您正在进行任何特定的日志记录或异常包装，否则可以将其删除。

如果您希望程序员知道有关可能的异常，请记录下来：

/// <summary>
/// Creates a new instance of <code>PointExtend</code>
/// </summary>
/// <param name="x">...</param>
/// <param name="y">...</param>
/// <param name="r">...</param>
/// <param name="g">...</param>
/// <param name="b">...</param>
/// <exception cref="InvalidColorValueException">Should the provided rgb values be out of range</exception>
public PointExtend(double x, double y, int r, int g, int b)
        : base(x, y)
    {            
            var color = new Color(r, g, b);
            Color = color;                            
    }

这将允许使用您的API的其他程序员知道构造函数的作用以及任何潜在的缺陷。不是每个人都可以访问您的代码。

编辑：根据@Philip Stuyck的评论，虽然我同意，但我也认为我们不是生活在一个理想的世界。你推荐的问题是：

如果您需要发送模糊版本的DLL，会发生什么？这是公司出售其DLL时通常会发生的情况。你无法真正研究代码，方法名称只能到目前为止。
大多数项目往往不仅仅是少数几个课程，每次通过代码来弄清楚发生了什么可能是耗时的，并且可能会让人们不再使用你的产品。在我看来，开源项目是this的一个明显例子。
最后，更重要的是，在我看来，您说出代码所做的唯一部分是在摘要部分（至少在.NET的情况下）。评论和文档应该阐明为什么是选择的给定方法。

Answer 2

如果您希望程序员知道某些内容，请使用评论。捕获和抛出异常是一种开销并且是无用的（除非你在重新抛出之前对其进行某些操作，即记录它），因此程序员实际上会感到困惑，认为存在错误并且不理解原始意图是什么。

Answer 3

如上所述，抛出上面的代码毫无意义，所有运行时都会抛出相同的异常。您可以删除try catch，它的功能也相同。

如果你对异常本身采取了一些抓住它的原因，那么就让它冒泡并给用户一个有意义的消息，将它记录在错误日志中，你和用户不仅仅是给出一个无意义的异常弹出：）

Answer 4

在这里，你真的得到了一些不好的建议，那些人试图说服你应该记录你的代码。

只有写得不好的代码才需要评论，而不是努力写评论，好评，在代码中花费精力，以便根本不需要评论。

这是否意味着所有评论都是邪恶的。不，当然不。有些情况下仍然需要评论，因为编程语言并不总是最适合描述正在发生的事情。但即便如此，也必须小心谨慎，因为评论将开始过自己的生活。

http://apdevblog.com/comments-in-code/

是指由Robert C. Martin提供 Clean Code

的博客

该书中有一整章关于评论，那些认为你需要评论的人更好地阅读这本书。

在您的特定情况下，如果您真的觉得代码在捕获异常时更好，然后无需额外重新抛出它，请务必将其保留。就个人而言，我会把它留下来。但对我来说，这只是一个风格问题。与您的同事达成协议，并在您的团队中保持一致。

我的回答可以引起很多争论，你可以自由发表自己对这个问题的看法。（罗伯特马丁说同样的事情;-)）但问题的真相是，在许多情况下，评论只会使代码混乱并降低可读性。注释忘记更新，因此不再与实际代码一致，...

记录所有内容的另一种方法是编写好的单元测试。通过阅读单元测试的代码，如果它们编写得很好，您将了解代码应该如何使用。那就是如果你正在写一个api供其他人使用。

编写良好的代码也很好地分层，不需要对系统中的每个类进行碾压。如果你必须这样做才能理解代码，那么结论又是一样的。这是糟糕的代码。

方法名称和变量名称，类名称都很远。在阅读了干净的代码之后，我已经大大改变了我的代码风格。

我现在正在编写软件已有20年了，我已经看过了，并写了很多评论。在许多情况下，仍然不清楚它们在评论中的真正含义，或者评论只是一种错误。

是否重新抛出异常良好做法？

4 个答案: