On Thu, 21 Apr 2022 19:28:08 GMT, Pavel Rappo <pra...@openjdk.org> wrote:
> Sometimes an exception is retrofitted into control flow to interrupt it in a > way that it wasn't originally designed to be interrupted. Such an exception > is an implementation detail. Once the exception is caught internally, it is > discarded. > > An exception has a stacktrace. Filling in a stacktrace is not free. Filling > in a stacktrace that won't be used seems like a waste. The changes for the `UncheckedIOException` wrappers look OK, but might be even better if the code properly unwrapped the wrapper and simply rethrew the underlying cause. For example, replace } catch (UncheckedIOException ex) { throw new IOException(ex.getMessage(), ex); with } catch (UncheckedIOException ex) { throw ex.getCause(); ``` For the `TreePath` and `DocTreePath` `Result` exceptions, a better solution would be to add an opt-in short-circuiting mechanism info the scanner's `scanAndReduce` method, to avoid calling additional calls of `scan` once some condition has been met, like a non-null result. This would completely avoid the need to throw an exception. ------------- Changes requested by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8347