On Thu, 21 Apr 2022 20:34:31 GMT, Jonathan Gibbons <[email protected]> wrote:
> 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();
> ```
>
Sounds reasonable; I'll have a look at it.
> 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.
I think that we discussed (some of) that before in the comment section of
another issue: JDK-8267690. You might want to re-read it.
What this PR proposes is to apply a band-aid until we're ready to treat the
issue properly. The treatment you are suggesting is proper, but heavyweight in
terms of the process: it involves an API change, which requires a CSR.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8347
