On Thu, 21 Apr 2022 19:28:08 GMT, Pavel Rappo <[email protected]> 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
