当前位置： 文江博客话题详情

为什么 NullPointerException 是运行时异常，而 RemoteException 不是？

发布于 2024-09-02 15:34:22 字数 247 浏览 4 评论 0原文

NullPointerException 是运行时异常的一个可能原因是每个方法都可以抛出它，因此每个方法都需要有一个“抛出 NullPointerException”，并且会很丑陋。但这会发生在 RemoteException 中。

由于 RemoteException 不是运行时异常，一个可能的原因是告诉客户端处理该异常。但远程环境中的每个方法都需要抛出它，因此与抛出 NullPointerException 没有区别。

猜测？我说清楚了吗？

原文

A possible reason because a NullPointerException is a runtime exception is because every method can throw it, so every method would need to have a "throws NullPointerException", and would be ugly. But this happens with RemoteException.

And a possible reason because RemoteException is not a runtime exception, is to tell it client to treat the exception. But every method in a remote environment need throws it, so there is no difference of throwing NullPointerException.

Speculations? Was I clear?

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（4）

小耗子 2024-09-09 15:34:22

我不会讨论这个决定，我只是引用 Ann Wollrath（Java RMI 的设计和实现的领导者）对这个决定的解释。这是从 消息（1999 年 1 月的消息）：

决定将 RemoteException 设为
检查异常并需要远程
方法来列出异常
throws 条款不是宗教条款。
该决定取决于如何做出
分布式计算可靠。这
问题每隔一段时间就会出现一次
在我们的用户列表中。我有一个
我发布的详细回复
不久前。这是如果你是的话
感兴趣的。我在 中找不到它
rmi-users 存档，所以我将其包含在内
下面。

干杯，

-- 安

<小时>

<块引用>

我想谈谈这样做的理由
使 RemoteException 成为已检查的
例外，而不是
运行时异常。

1) 网络不可靠

我希望他们是这样，但事实上，
他们不是。每个网络都有
瞬时故障。您可以内置
网络冗余，但事实是
大多数网络都没有这个功能。
Intranet 会出现暂时性故障，例如
互联网。所以，每一个 RPC 制作，
会失败。的类型
失败可能没有任何关系
与“网络”本身；如果你的
服务器用完文件描述符，
您的客户端将获得连接
例外。这不是网络
网络意义上的失败
被打破；你的服务器位于
资源的短暂状态
饿死了。

RMI 的设计目的不仅仅是处理
全网有限情况
当单台机器崩溃时就会崩溃。
这样的网络将被考虑
可靠，要么一切正常，要么
一切都崩溃了——没有
部分失败。 RMI 的目标是
更广泛的受众。

2) RPC失败无法隐藏
客户端

部分失败是一个事实
分布式编程；这些
失败不能被隐藏
程序。失败出现在
客户端，是否异常
检查或未检查的异常，它
仍然出现。那么，这样的情况应该如何
向客户端指示失败？

3) 检查异常促进更多
强大的程序

曾经有一段时间，橡树和
最早的Java版本没有
检查异常。异常处理
是建议性的，而且是不安全的
外面的世界。这是我们的小组（吉姆
尤其是沃尔多和我:-)
建议有例外情况
由编译器检查。吉姆相当
他的论点有说服力，讲述
一个健壮的代码将实现的世界
在位。经过一番考虑，Java
被重新装备以检查
例外情况。只有那些例外情况
没有恢复或反映
应用程序错误将不受检查
（例如，内存不足错误，
分别为 NullPointerException）。
世界又安全了。

想象一下 Java 工程师的惊讶吧
当Java API出现很多异常时
和编译器更改为
未选中变为选中，编译器
强制执行这种区别，他们
发现实施中的错误！
因此，尽最大努力处理错误
条件，无论意图多么好，
还不够好。那个编译器是
对某些事情有用:-)

4) RemoteException 应该是经过检查的
异常

好的，回到正轨吧。自从一个
RemoteException 是生活中的一个事实
RPC 调用（参见 #1、#2）并检查
异常迫使你安全地编写
代码（#3），我们认为
RemoteException 已检查异常
是个好主意。书写稳健
分布式程序已经够难了，
无需编译器的帮助
但你例外。

因此，有些人可能会认为
RemoteException 就像一个
内存不足错误；你的程序应该
如果远程调用失败，就会摔死。
我不同意这一点。是的，在
在某些情况下，无法恢复
远程异常；但如果你是
编写一个可靠的分布式
程序，你的客户需要抓住
失败并适当重试。
也许您需要联系另一个人
服务器，或中止某些事务
种类。如果 RemoteException 不是
处理后，它会向上渗透并
让你的客户端崩溃（yuk）。

其他人表示有一些
远程接口用于
本地情况和远程情况
案例和客户不应该
处理本地的异常
情况，所以 RemoteException 不应该
必须在 throws 子句中并且
处理它不应该是强制性的。
现在，如果我们允许远程接口
省略 RemoteException 的方法和
有一个“rmic”开关来生成存根
这会抛出一个未经检查的
RemoteException，客户端有没有
事中的选择。的决定
异常处理应该保留
客户。如果你定义了一个接口
只抛出未经检查的异常
你永远不可能写出这样的客户
需要编译器帮助处理
那些例外。我们已经
从上面的例子可以看出
检查异常促进稳健
代码。

现在出现的另一个问题
再次是开发人员需要
只需翻译本地接口和
将它们用作远程接口。这
可能适用于一小部分情况，但是
如果界面设计时没有使用
并发和部分失败以及
考虑到呼叫延迟，协议
接口捕获的可能不是
适合在分布式中使用
案件。传入的信息是否足够
这些操作使
操作幂等？也许吧，但是
很可能不会。

将 RemoteException 放入每个
throws 子句可能看起来很痛苦，
但这是写作所付出的代价
强大的分布式应用程序。

--安·沃尔拉斯

I won't discuss the decision, I'll just quote the explanation of the decision from Ann Wollrath (who lead the design and implementation of Java RMI). This is extracted from this message from the RMI-USERS archives (message from Jan 1999):

The decision to make RemoteException a
checked exception and requiring remote
methods to list the exception in its
throws clause is not a religious one.
The decision is based on how to make
distributed computing reliable. This
question comes up every once in a
while on our users list. I have a
detailed response that I posted a
while ago. Here it is if you are
interested. I couldn't find it in the
rmi-users archive, so I included it
below.

cheers,

-- Ann

I'd like to address the rationale for
making RemoteException a checked
Exception, rather than a
RuntimeException.

1) networks aren't reliable

I wish that they were, but in fact,
they're not. Every network has
transient failures. You can build in
network redundancy, but the fact is
that most networks don't have that.
Intranets have transient failures, as
does the Internet. So, every RPC made,
is subject to a failure. The types of
failures may not have anything to do
with the "network", per se; if your
server runs out of file descriptors,
your client will get a connect
exception. This isn't a network
failure, in the sense of the network
being broken; your server is in a
transient state of being resource
starved.

RMI is not designed to only handle the
limited case that the whole network
crashes when a single machine crashes.
Such a network would be considered
reliable, either everything is up or
everything is down--there is no
partial failure. RMI is targetted for
a more general audience.

2) RPC failure can't be hidden from
the client

Partial failure is a fact of
distributed programming; these
failures can't be hidden to the
program. A failure shows up in the
client, whether the exception is
checked or unchecked exception, it
still shows up. So, how should such
failures be indicated to the client?

3) checked exceptions foster more
robust programs

There was a time when Oak and the
earliest version of Java did not have
checked exceptions. Exception handling
was advisory, and it was an unsafe
world out there. It was our group (Jim
Waldo and me in particular :-) that
recommended that there be exceptions
checked by the compiler. Jim was quite
persuasive in his arguments, telling
of a world where robust code would
reign. After some consideration, Java
was retooled to have checked
exceptions. Only those exceptions for
which there was no recovery or reflect
application errors would be unchecked
(e.g., OutOfMemoryError,
NullPointerException respectively).
And the world was safe again.

Imagine the Java engineers' surprise
when many exceptions in the Java API
and compiler were changed from
unchecked to checked, and the compiler
enforced the distinction, they
uncovered bugs in the implementations!
So, the best efforts at handling error
conditions, however well intentioned,
was not good enough. That compiler is
useful for something :-)

4) RemoteException should be a checked
exception

Ok, so back on track here. Since a
RemoteException is a fact of life in a
RPC call (see #1, #2) and checked
exceptions force you to write safe
code (#3), we thought that making
RemoteException a checked exception
was a good idea. Writing robust
distributed programs is hard enough,
without having the compiler to help
you with exceptions.

So, some might argue that a
RemoteException is a like an
OutOfMemoryError; your program should
fall over dead if a remote call fails.
I disagree with this point. Yes, in
some cases, there is no recovery from
a RemoteException; but if you are
writing a reliable distributed
program, your client needs to catch
failures and retry appropriately.
Perhaps you need to contact another
server, or abort a transaction of some
sort. If the RemoteException is not
handled, it will percolate up and
crash your client (yuk).

Others have stated that there are some
remote interfaces that are used in
both the local case and the remote
case and the client should not have to
deal with the exceptions in the local
case, so RemoteException should not
have to be in a throws clause and
handling it should not be mandatory.
Now, if we allowed remote interface
methods to omit RemoteException and
had an "rmic" switch to generate stubs
that would throw an unchecked
RemoteException, the client has no
choice in the matter. The decision of
exception handling should remain with
the client. If you define an interface
that only throws unchecked exceptions
you can never write a client that
wants compiler help in dealing with
those exceptions. We have already
seen from the above example that
checked exceptions fosters robust
code.

Another issue that has popped up now
and again is that developers need to
simply translate local interfaces and
use them as remote interfaces. This
may work for a small set of cases, but
if the interface was not designed with
concurrency and partial failure and
call latency in mind, the protocol
captured by the interface may not be
appropriate to use in the distributed
case. Is enough information passed in
those operations to make the
operations idempotent? Perhaps, but
most likely not.

Putting RemoteException in every
throws clause may seem like a pain,
but its the price to pay for writing
robust distributed applications.

-- Ann Wollrath

回复 原文
ぃ弥猫深巷。 2024-09-09 15:34:22

NullPointerException 比 RemoteException 的潜力要大得多。任何调用对象方法的代码（实际上是指任何 Java 代码）都可能抛出 NullPointerException。只有 RMI 代码可以抛出 RemoteException。这是“所有代码”的一小部分。

在编写 RMI 库时，设计者决定让客户端代码能够处理这些异常。考虑到远程代码执行的性质，我认为这是合理的。

There is vastly more potential for NullPointerException than RemoteException. Any code that calls a method on an object (meaning practically any Java code at all) could potentially throw a NullPointerException. Only RMI code can throw a RemoteException. This is a tiny subset of "all code."

When writing the RMI libraries, the designers decided to make the client code expect to deal with these exceptions. Considering the nature of remote code execution, I think that's reasonable.

回复 原文
一影成城 2024-09-09 15:34:22

我的理解是：

  • 运行时异常是针对可以预防的事情抛出的。
  • 对于无法预防但可恢复的事情会引发异常
  • 对于无法预防且无法恢复的事情会引发错误。

例如，NullPointerException 始终可以避免，因此是未经检查的异常。当存在网络故障时，可能会发生 RemoteException，而在方法调用之前无法合理阻止该故障，因此需要进行检查。

The way I understand it is:

  • RuntimeExceptions are thrown for things that were preventable.
  • Exceptions are thrown for things that were unpreventable but recoverable
  • Errors are thrown for things that were unpreventable and unrecoverable.

For example, NullPointerExceptions can always be avoided and are therefore unchecked exceptions. A RemoteException could occur when there is a network failure, which cannot be reasonably prevented before the method call and therefore is checked.

回复 原文
記柔刀 2024-09-09 15:34:22

除了 RemoteException 仅适用于 java.rmi 和 javax.rmi 包（及其子包）中的代码之外，RemoteException是一种IOException类型，很像SocketException是...并且所有IOException都是检查异常。

Besides RemoteException only applying to code from java.rmi and javax.rmi packages (and their subpackages), RemoteException is a type of IOException, much like SocketException is... and all IOExceptions are checked exceptions.

回复 原文
~没有更多了~

关于作者

蓝眸

暂无简介

0 文章
0 评论
22 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

留蓝

文章 0 评论 0

18790681156

文章 0 评论 0

zach7772

文章 0 评论 0

Wini

文章 0 评论 0

ayeshaaroy

文章 0 评论 0

初雪

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文