<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">On 04/09/2025 04:15, david Grajales
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CADFQZ76GB4FG9awaqEY5zFE8DGecYEq7F6BazzyTRuiS2MyxbQ@mail.gmail.com">
<div dir="ltr">:<br>
<div><br>
</div>
<div>
<p>One thing I noticed is that having to declare <code>Void</code>
and return <code>null</code> introduces a bit of noise.
This ceremony is required because <code>Runnable</code>
doesn’t allow checked exceptions in its contract (and never
will, for backwards compatibility). Yet, in practice, many
real-world tasks don’t return values directly — instead,
they write to or consume from buffers.</p>
<p>This makes the <code>Void</code> return type and <code>return
null</code> feel redundant. I was wondering: would it be
worth considering the addition of a <code>Runnable</code>-like
functional interface that permits checked exceptions?</p>
</div>
</div>
</blockquote>
<br>
Runnable and Callable are familiar to all of APIs in this area.
We've avoided introducing throwing-Runnable or throwing-Supplier
functional interfaces as adding any throwing interface to
j.u.function opens the door to requests to add more. It might also
be that someday there are changes to the language for exception
transparency or maybe allowing overriding with an unboxed return. So
maybe in the future need for such interfaces may go away (I can't
speak to any specific plans of course, instead just saying that
we've been conservative about adding throwing variants that could
potentially be obsolete in the future).<br>
<br>
-Alan.<br>
</body>
</html>