Question

我想知道为什么有些方法会抛出Exception而不是返回null？

例如Class.forName(String className)方法抛出ClassNotFoundException。如果被叫方想要通知我们为什么不返回null，我们可以使用if检查结果，而不必写try-catch块。

为什么不这样写：

try{
    Class<?> c = Class.forName("foo.Bar");
} catch(ClassNotFoundException e){
    ...
}

像这样：

Class<?> c = Class.forName("foo.Bar");
if(c != null) {
    ...
} else {
    //handle that class wasn't found
}

为什么使用Exceptions，可能有特定值要返回（最好null或有时-1），以通知调用者操作失败？我知道如果方法可以更多地失败，调用者可以根据错误消息将反应分开，但在这种情况下，当类无法＆＃时，ClassNotFoundException仅 抛出39;找不到。

还有性能问题，返回null的速度要比抛出Exception更快吗？

Answer 1

从调用者的角度来看，通常在代码块中处理异常比检查返回代码更容易。例如，如果您想调用可能失败的两个函数，该怎么办？然后你有类似的东西：

if (functionAWorks()) {
  ...
  if (functionBWorks()) {
    ...
  }
  else {
    ...
  }
}
else {
  ...
}

而不是：

  try {
    functionA();
    functionB();
  } catch (Exception e) {
    ...
  }

通常，构造返回代码处理的麻烦通常会导致人们根本不检查返回代码。

从被调用者的角度来看，抛出异常通常是一种更简洁的方式来指示失败而不是返回代码，并且它提供了调用者堆栈跟踪信息，这对于调试非常有用。

表现是一个不同的问题。可以说，如果您选择为项目使用托管语言，那么您已经选择不担心微观性能问题。

Answer 2

请注意，该方法也可以抛出LinkageError或ExceptionInInitializeError。您可能希望决定针对不同的例外执行不同的操作。

我同意这样的评论：返回异常比返回null更具信息性，而且你不应该担心性能。

与此案例无关，但对于只抛出一个异常的情况，可以改为返回null。找不到要求的东西是个例外吗？一个异常的情况？然后抛出异常...这只是一个正常的情况吗？返回null。这是一个设计选择，在任何情况下都应该很好地记录调用方法的预期结果。文档就像实现方法的人和调用它的人之间的契约。

此外，在像Scala这样的语言中，可以调用一个返回Option的方法，该方法可以有一个值或None，以防该方法找不到要返回的内容。