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 <[email protected]> wrote: > > I agree that symmetry with the IOException would be better. > > > On Oct 21, 2025, at 7:51 AM, Pavel Rappo <[email protected]> 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
