RFR: 8285396: Do not fill in the stacktrace of an internal exception

Pavel Rappo prappo at openjdk.java.net
Thu Apr 21 22:14:27 UTC 2022


On Thu, 21 Apr 2022 20:34:31 GMT, Jonathan Gibbons <jjg at 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


More information about the compiler-dev mailing list