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

Reply via email to