My 2¢: Something akin to "exception transparency" would be a much more palatable solution (to me), otherwise it'll just lead to a proliferation of UncheckedX-exception types in general, sort of defeating the entire purpose of checked exceptions.
Cheers, √ Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: loom-dev <[email protected]> on behalf of Pavel Rappo <[email protected]> Sent: Wednesday, 22 October 2025 11:44 To: Alan Bateman <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: StructuredTaskScope.TimeoutException vs UncheckedTimeoutException On Wed, Oct 22, 2025 at 7:26 AM Alan Bateman <[email protected]> wrote: > > > If a timeout is configured when opening a new StructuredTaskScope then it > applies to the scope. If the timeout expires before the scope is closed then > the timeout causes the scope to be cancelled and join to wakeup. Declaring > join to throw the checked-TimeoutException would be very annoying when not > using a timeout or in the update, when there is other outcome when the > timeout expires. For the record, at no point was I suggesting to use a checked exception instead. Using a checked exception there unconditionally would be annoying for sure. > One of these years, there will be progress on the topic of exception > transparency. It's impossible to know how this might look but there is a good > chance that it will shine a light on past decisions to introduce UncheckedXXX > exceptions. Introducing UncheckedTimeoutException would invite more usages, > way beyond the very specific need here. I thought that more usages might be good. My main concern here is the possibility of a clash between two like-named exceptions, one of which is checked and the other one isn't. But I guess you don't see this as an issue. That's okay; thanks. -Pavel
