Why does `ScopedValue.where(SCOPE_VALUE, val).call()` throw Exception?

[Josiah Noel]

Indeed, that is something we could do (in fact it's better than what I was
doing).

But why have everybody create boilerplate to uncheck the exception, when
you could add a supply method for the cases where we don't expect a checked
exception?

Is there a reason not to add a supplier method?

On Fri, Mar 24, 2023, 5:59 AM Andrew Haley <aph-open at littlepinkcloud.com>
wrote:

> On 3/23/23 19:46, Kasper Nielsen wrote:
> > But right now I'm using
> > try {
> >    return ScopedValue.where(S, value, callable);
> > } catch (RuntimeException e) {
> >    throw e;
> > } catch (Exception e) {
> >    throw new UndeclaredThrowableException(e);
> > }
>
> Surely you could write something like
>
>      public static <T> T call(ScopedValue.Carrier aCarrier, Callable<T>
> aCallable) {
>         try {
>           return aCarrier.call(aCallable);
>         } catch (RuntimeException e) {
>           throw e;
>         } catch (Exception e) {
>       throw new UndeclaredThrowableException(e);
>     }
>
> ... and then use it everywhere as
>
>     return call(ScopedValue.where(s, value), callable);
>
> ... or even wrap the ScopedValue.Carrier class to give you exactly what
> you need.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230324/3a02148c/attachment.htm>