抛出异常是好的做法吗？

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说，catch-throw子句是多余的，我同意，考虑到我对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时，通常会发生这种情况。 您无法真正查看代码，方法名称只能走这么远。
• 大多数项目往往不仅仅是少数几个类，并且每次都要通过代码来确定正在发生的事情是很耗时的，并且会使人们无法使用您的产品。 开源项目，在我看来，一个明显的例子此 。
• 最后，更重要的是，我认为，您唯一可以说出代码功能的部分是在“ 摘要”部分（至少在.NET中如此）。 评论和文档应阐明为什么选择了给定的方法。

Answer 2

如果您希望程序员了解某些内容，请使用注释。 捕获和抛出异常是一项开销，并且是无用的（除非您在重新抛出异常之前对其进行了某些操作，即将其记录下来），所以程序员实际上会感到困惑，认为存在错误并且不了解原始意图。

Answer 3

就像您说的那样，上面的代码没有意义，所有运行时所要做的就是重新抛出相同的异常。 您可以删除try catch，它的功能相同。

如果您使用异常本身进行了某些操作（这是捕获该异常的原因），否则让其冒泡并向用户提供有意义的消息，请将其记录在错误日志中，您会发现弹出的废话异常并不仅是向用户显示： ）

Answer 4

试图说服您应该记录代码的人们在这里真的收到了不好的建议。

只有写得不好的代码才需要注释，而不是费力地编写注释，好的注释，而是将精力花在代码中，从而根本不需要注释。

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

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

是由Robert C. Martin撰写的有关Clean Code的博客

那本书中有一整章是关于注释的，那些认为您需要注释的人最好读一本书。

在您的特定情况下，如果您确实感觉到在捕获异常然后不加多余地重新抛出该异常时，代码会更好，请务必将其保留。我个人将其保留。 但是对我来说，这只是样式问题。 与您的同事达成协议，并保持团队一致。

我在这里的回答可能引起激烈的辩论，大家对此问题都有自己的见解。 （罗伯特·马丁（Robert Martin）说了同样的话；-)。但事实是，在许多情况下，注释只会使代码混乱，并降低可读性。 注释被忘了要更新，因此不再与实际代码内联，...

记录所有内容的另一种方法是编写良好的单元测试。 通过阅读单元测试的代码（如果编写得当的话），您将对应该使用的代码有所了解。 也就是说，如果您正在编写供其他人使用的api。

编写良好的代码也可以进行分层，而无需将其压缩到系统中的每个单个类上。 如果您必须这样做以便理解代码，那么结论还是相同的。 这是错误的代码。

方法名，变量名，类名走得很远。 在阅读了干净的代码书之后，我对代码样式进行了相当大的更改。

我从事软件开发已有20年了，我已经看过并写了很多评论。 在许多情况下，仍不清楚它们在该评论中的真正含义，或者该评论是完全错误的。