代码之家  ›  专栏  ›  技术社区  ›  Daniel Rikowski

尽早抛出异常是一个好的实践吗?

  •  4
  • Daniel Rikowski  · 技术社区  · 14 年前

    今天我遇到了以下情况:(伪代码)

    class MyClass {
    
        public void workOnArray(Object[] data) {
            for (Object item : data) {
                workOnItem(item);
            }
        }
    
        public void workOnItem(Object item) {
            if (item == null) throw new NullPointerException();
        }
    }
    

    如果来电者打电话 workOnArray 数组包含 null 项目,调用方将获得 NullPointerException 因为 workOnItem .

    但我可以插入一个 额外的 登记入住 工作阵列 也就是说,可以更快地发现问题。

    (请注意,这是一个微不足道的示例,在实际应用程序中,这可能不太明显)。

    在专业方面,我认为额外的检查可以提供更多的高级诊断信息。及早失败也是一件好事。

    相反,我会问自己:“如果我这样做,我是否应该验证传递到编程语言核心API的每个参数,并抛出完全相同的异常?”

    什么时候尽早抛出异常,什么时候让被调用方抛出异常,有什么经验法则吗?

    2 回复  |  直到 14 年前
        1
  •  8
  •   Andrew Barber Eric Lafortune    14 年前

    在这样的循环处理项目的情况下,有一件事肯定会让我想先预验证整个项目数组;如果在引发异常之前对某些要处理的项目不好,则会使任何剩余的项目未处理。

    除非使用某种包装代码的事务机制,否则我通常希望在开始处理集合中的项之前,能够保证它们是有效的。

        2
  •  2
  •   John Bledsoe    14 年前

    在本例中,WorkOnItem方法是一个关心项是否为空的方法。WorkOnArray方法不关心项是否为空,因此IMO不应该验证任何项是否为空。WorkOnItem方法确实很重要,因此应该执行检查。

    我还考虑从WorkOnItem中抛出更合适的异常类型。NullPointerException(或在C,NullReferenceException中)通常指示方法操作中的某些意外缺陷。在C中,我更倾向于抛出包含空参数名称的ArgumentNullException。这更清楚地表明WorkOnItem无法继续,因为它无法处理接收空参数的问题。