在异常被捕获错设计后返回null

Question

我总是遇到同样的问题,当在具有非void返回值的函数中捕获异常时,我不知道要返回什么.以下代码段说明了我的问题.

public Object getObject(){
  try{
    ...
    return object;
  }
  catch(Exception e){
    //I have to return something here but what??
    return null; // is this a bad design??
  }
}

所以我的问题是:

• 返回null设计不好吗？
• 如果是这样,什么被视为更清洁的解决方案？

谢谢.

Answer 1

如果你真的无法处理它,我会说不要抓住异常.并且不会考虑记录处理错误.最好把它冒充给可以抛弃异常的人.

如果你必须返回一个值,并且null是唯一明智的东西,那就没有错.只需记录下来并向用户说明应该做什么.有一个单元测试,显示抛出的异常,所以开发人员可以看到你所接受的成语需要什么.它还将测试以确保您的代码在应该的时候抛出异常.

Answer 2

我总是遇到同样的问题,当在具有非void返回值的函数中捕获异常时,我不知道要返回什么.

如果您不知道要返回什么,那么这意味着您不知道如何处理异常.在那种情况下,重新抛出它.请不要悄悄地吞下它.请不要返回null,你不想强制代码的调用者写:

Foo foo = bar.getFoo();
if (foo != null) {
    // do something with foo
} 

这是恕我直言,一个糟糕的设计,我个人不喜欢写空检查(很多时候,使用null,而不是应该抛出异常).

所以,正如我所说,throws在方法中添加一个子句,或者完全远程的try/catch块,或者如果有意义的话,保留try/catch(例如,如果你需要处理几个异常)并按原样重新抛出异常或者将其包装在自定义异常中.

相关问题

• 如何避免Java中的"!= null"语句？

Answer 3

最重要的是,我不想返回null.这是用户必须明确记住作为特殊情况处理的事情(除非他们期望为空 - 这是记录的).如果他们很幸运,他们会立即尊重它并遭受错误.如果他们运气不好,他们会把它粘在一个集合中,以后会遇到同样的问题.

我想你有两个选择:

1. 抛出一个例外.这样客户端必须以某种方式处理它(因此我要么记录它和/或检查它).缺点是异常很慢并且不应该用于控制流程,因此我将此用于特殊情况(双关语)
2. 您可以使用NullObject模式.

我遵循编码风格,我很少返回null.如果/当我这样做时,这是明确记录的,以便客户可以满足它.

Answer 4

例外表示特殊情况.假设你的代码应该返回一个对象,那么路上一定有问题(网络错误,内存不足,谁知道？)因此你不应该只是通过返回null来躲避它.

但是,在许多情况下,您可以在文档中看到方法在发生此类情况时返回null.然后该类的客户端可以依赖此行为并处理返回的null,没有什么不好的.在第二个用法示例中,请参见它不是一个例外情况 - 该类被设计为在某些条件下返回null - 因此这样做完全没问题(但是要记录这个预期的行为).

因此,在一天结束时,它实际上取决于你是否因为某种特殊的方式而无法返回物体,或者你根本没有物体返回,这绝对没问题.