<!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>