2020-08-07

关于Java异常最详细透彻的理解（3）

异常处理逻辑

编译时异常：Java代码本身不存在语法语义上的错误，更不存在逻辑性错误，但因为外在的环境条件不满足（输入输出异常即IOException），从而可能导致程序无法正常运行。例如：用户错误及I/O问题----程序试图打开一个并不存在的远程Socket端口。这不是程序本身的逻辑错误，而很可能是远程机器名字错误(用户拼写错误)。对商用软件系统，程序开发者必须考虑并处理这个问题。Java编译器强制要求处理这类异常，如果不捕获这类异常，程序将不能被编译。
运行期异常： 这意味着程序在逻辑上有缺陷，有bug，如数组越界，0被除，入参不满足规范…这类异常需要更改程序来避免，Java编译器不强制要求处理这类异常。
错误： 一般很少见，也很难通过程序解决。它可能源于程序的bug，但一般更可能源于环境问题，如内存耗尽。错误在程序中无须处理，而有运行环境处理。

  以下为Java rmi设计者相关解答

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