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