StructuredTaskScope.TimeoutException vs UncheckedTimeoutException

[Pavel Rappo]

While symmetry might be good in itself, public
UncheckedTimeoutException could also be used by others. By contrast,
StructuredTaskScope.TimeoutException is highly-specific exception that
has package access, so it cannot be instantiated outside
java.util.concurrent.

Separately, I was thinking about the possibility of a clash between
java.util.concurrent.TimeoutException and
java.util.concurrent.StructuredTaskScope.TimeoutException in the same
file. Using longer names to disambiguate those is always possible, but
it might not look pretty.

-Pavel

On Tue, Oct 21, 2025 at 2:15 PM Robert Engels <robaho at me.com> wrote:
>
> I agree that symmetry with the IOException would be better.
>
> > On Oct 21, 2025, at 7:51 AM, Pavel Rappo <pavel.rappo at gmail.com> wrote:
> >
> > As suggested in a PR thread [*], I bring this question to loom-dev:
> >
> > I haven't been paying much attention to the recent previews of this
> > feature, so feel free to point me to a relevant discussion elsewhere.
> >
> > As I understand it, an unchecked StructuredTaskScope.TimeoutException
> > was added in JDK 25. There's also the well-known checked
> > java.util.TimeoutException. I assume that the namesake exception was
> > added solely because it's unchecked. I also assume
> > UncheckedTimeoutException was considered at some stage, because in my
> > mind, the situation is similar to that of
> > IOException/UncheckedIOException.
> >
> > Why did you choose to add a namesake instead of an unchecked wrapper
> > exception? Was it because you consider that the likelihood of mixing
> > the two TimeoutException's is low in the context of a single file?
> >
> > -Pavel
> >
> > [*]: https://github.com/openjdk/jdk/pull/27392#issuecomment-3426369195