return null 和 throw 异常有什么区别？答案

【问题标题】：what is different between return null and throw exception?return null 和 throw 异常有什么区别？
【发布时间】：2020-12-20 01:10:40
【问题描述】：

@Override
public IBinder onBind(Intent intent) {
    // TODO: Return the communication channel to the service.
    throw new UnsupportedOperationException("Not yet implemented");
}

这个方法有一个IBinder作为返回值，但是它只是抛出一个异常，我的问题不是关于服务，我的问题是为什么这个方法没有显示编译器错误？

如果我们写return null（如果我们不想实现这个方法）或者我们写抛出异常有什么不同？

【问题讨论】：

UnsupportedOperationException 是“错误”，而不是“异常”。在这种情况下，它的目的是让应用程序在运行时崩溃，以此告诉您您忘记了做某事，因此在这种情况下返回 null 不会达到预期目的
@MadProgrammer 由于UnsupportedOperationException 的名称中有“异常”一词，并且继承自Exception，因此将其称为异常似乎足够公平。
@khelwood 公平点 - 这是RuntimeException - 意图保持不变（过去几年一直在使用 Swift，所以我现在习惯于声明异常意图：P） - 我会争辩说，在这种情况下，其意图不是catch 异常，而是允许应用程序崩溃以提醒开发人员他们应该在这里做点什么——如果他们选择返回null，那就是他们选择的实施细节
异常可能会被其他类捕获。

标签： java return throw

【解决方案1】：

通常，抛出异常会更好，因为它比返回 null 提供的信息要多得多，而且调用代码不能随便忽略返回的值，从而导致后续的无信息 NullPointerException。

但是，the documentation for onBind 明确表示可以返回 null。由于这就是 API 的设计方式，因此在这种特殊情况下返回 null 比抛出异常更有意义。

一般来说，抛出异常更好，因为它可以防止调用代码假设可以继续，就好像操作成功而实际上并没有成功一样。但是在这种情况下，该方法实际上应该在不支持操作时返回 null（在我看来这不是一个好的设计决策）。

【讨论】：

【解决方案2】：

return null 返回一个空值。 throw new 抛出的任何异常都会中止方法的执行并引发指定类型的异常。在这种情况下抛出异常不会显示编译器错误，因为如果这是您唯一要做的事情，您将永远不会返回任何东西，这也是有效的。例如，如果异常是在 if/else 的一个分支中引发的，则您需要在另一个分支中引发异常或返回一个值，或者您会收到编译器错误，告诉您必须返回一个IBinder 类型的值。

【讨论】：