RFR: 8275319 java.net.NetworkInterface throws java.lang.Error instead of SocketException

[Daniel Jeliński]

On Fri, 15 Oct 2021 03:30:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Hello @djelinski, 
> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
> 
> I have created https://bugs.openjdk.java.net/browse/JDK-8275319 to track this. For this PR to trigger the PR review process, you will now have to update the PR title to match the bug id and bug title (and I think even the commit message should refer to the same).

@jaikiran thanks for the JBS. Editing PR title was sufficient.

> Is there any concrete case where an Error was observed?

It happens occasionally, as evidenced by JDK-8217298, JDK-8046500 (fixed), JDK-8165665, JDK-8066931, JDK-8057900, JDK-8065559(closed), JDK-8040229, JDK-8065078(fixed), JDK-8068597(fixed), numerous reports on Google (search for "error IP Helper Library"), and an ancient note found in my company's codebase, possibly no longer relevant.

> if MultiByteToWideChar fails

I started checking how such failures are handled elsewhere in JDK codebase, and the results are pretty inconsistent: [ignore result](https://github.com/openjdk/jdk/blob/7f52c50ba32eecf5f379f8db30ac6a5cc50b3b66/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L722), [normal error handling](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/native/libzip/zip_util.c#L147), [native assert](https://github.com/openjdk/jdk/blob/97ea9dd2f24f9f1fb9b9345a4202a825ee28e014/src/hotspot/os/windows/os_windows.cpp#L4435), and Java error in NetworkInterface. Some consistency here would be nice, but then, I don't know which option I would pick. Google couldn't find any cases of "Error Cannot get multibyte", so I guess that doesn't happen too often.

> Error or InternalError

There are only 2 places in Java codebase where Error is thrown, one is NetworkInterface, the other one is [here](https://github.com/openjdk/jdk/blob/bebfae48e3f1643f2456d680d170dcc22f7231bf/src/java.base/unix/native/libjava/java_props_md.c#L508). `JNU_ThrowInternalError` is definitely the more popular option.

Still, I'd argue that even if an unhandled error in IP helper library indicates a bug in JDK, throwing a checked exception is a better option here, because:
- these errors do not indicate that the JVM is broken / unusable, at least not any more than it was before the function was called. They do not affect global JVM state in any way
- a checked exception is less likely to go unnoticed (uncaught Error will usually terminate one thread, and let other threads continue; checked exception needs to be handled by user code)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5956