On Fri, 15 Oct 2021 03:30:49 GMT, Jaikiran Pai <j...@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
