On Thu, 21 Apr 2022 20:34:31 GMT, Jonathan Gibbons <j...@openjdk.org> 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