<div dir="ltr"><div class="markdown-here-wrapper" style=""><blockquote style="margin:1.2em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:0px 0px 1.2em!important">There is no proper union types in the Java type system so no way to union several exceptions as one type parameter so even if j.u.f interfaces where parametrized by an exception type, the stream API could not have using them properly.</p>
</blockquote>
<p style="margin:0px 0px 1.2em!important">This is correct (although union type alone is not enough for the Stream API, see [1]), but this is not an excuse to not add a better standards for other places (e.g. the ScopedValues)</p>
<blockquote style="margin:1.2em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:0px 0px 1.2em!important">need to single out InterruptedException</p>
</blockquote>
<p style="margin:0px 0px 1.2em!important">It honestly escaped my mind, greate point.</p>
<p style="margin:0px 0px 1.2em!important">If we are already on the subject, as you stated, STS#handleComplete has only 2 possible states, success and failure, so why not completely separate them:</p>
<p style="margin:0px 0px 1.2em!important">STS#handleSuccess(T result, Callable task [, boolean cancelled])<br>STS#handleFailure(Throwable exception, Callable task [, boolean cancelled]) (note that we can’t use parameterize exception here)</p>
<p style="margin:0px 0px 1.2em!important">[1] <a href="https://mail.openjdk.org/pipermail/amber-dev/2023-March/007858.html">https://mail.openjdk.org/pipermail/amber-dev/2023-March/007858.html</a></p>
<div title="MDH:PGJyPjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBh
cmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7Ij4mZ3Q7Jm5ic3A7
PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogYXJp
YWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNnB4OyI+VGhlcmUgPHNwYW4g
emV1bTRjMT0iUFJfMzBfMCIgZGF0YS1kZG53YWI9IlBSXzMwXzAiIGFyaWEtaW52YWxpZD0iZ3Jh
bW1hciIgY2xhc3M9IkxtIG5nIj5pcyBubzwvc3Bhbj4gcHJvcGVyIHVuaW9uIHR5cGVzIGluIHRo
ZSBKYXZhIHR5cGUgc3lzdGVtIHNvIG5vIHdheSB0byB1bmlvbiBzZXZlcmFsIGV4Y2VwdGlvbnMg
YXMgb25lIHR5cGUgcGFyYW1ldGVyIHNvIGV2ZW4gaWYgai51LmYgaW50ZXJmYWNlcyA8c3BhbiB6
ZXVtNGMxPSJQUl8zMV8wIiBkYXRhLWRkbndhYj0iUFJfMzFfMCIgYXJpYS1pbnZhbGlkPSJncmFt
bWFyIiBjbGFzcz0iTG0gbmciPndoZXJlPC9zcGFuPiBwYXJhbWV0cml6ZWQgYnkgYW4gZXhjZXB0
aW9uIHR5cGUsIHRoZSBzdHJlYW0gQVBJIGNvdWxkIG5vdCBoYXZlIDxzcGFuIHpldW00YzE9IlBS
XzMyXzAiIGRhdGEtZGRud2FiPSJQUl8zMl8wIiBhcmlhLWludmFsaWQ9ImdyYW1tYXIiIGNsYXNz
PSJMbSBuZyI+dXNpbmc8L3NwYW4+IHRoZW0gcHJvcGVybHkuPC9zcGFuPjwvZGl2PjxkaXY+PHNw
YW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbCwgaGVsdmV0
aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7Ij48YnI+PC9zcGFuPjwvZGl2PjxkaXY+
PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbCwgaGVs
dmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7Ij5UaGlzIGlzIGNvcnJlY3QgKGFs
dGhvdWdoIHVuaW9uIHR5cGUgYWxvbmUgaXMgbm90IGVub3VnaCBmb3IgdGhlIFN0cmVhbSBBUEks
IHNlZSBbMV0pLCBidXQgdGhpcyBpcyBub3QgYW4gZXhjdXNlIHRvIG5vdCBhZGQgYSBiZXR0ZXIg
c3RhbmRhcmRzIGZvciBvdGhlciBwbGFjZXMgKGUuZy4gdGhlIFNjb3BlZFZhbHVlcyk8L3NwYW4+
PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6
IGFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsiPjxicj48L3Nw
YW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p
bHk6IGFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsiPiZndDsm
bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5
OiBhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7Ij5uZWVkIHRv
IHNpbmdsZSBvdXQgSW50ZXJydXB0ZWRFeGNlcHRpb248L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBz
dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IGFyaWFsLCBoZWx2ZXRpY2Es
IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3Bh
biBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IGFyaWFsLCBoZWx2ZXRp
Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsiPkl0IGhvbmVzdGx5IGVzY2FwZWQgbXkg
bWluZCwgZ3JlYXRlIHBvaW50Ljwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjog
cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsg
Zm9udC1zaXplOiAxNnB4OyI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xv
cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJp
ZjsgZm9udC1zaXplOiAxNnB4OyI+SWYgd2UgYXJlIGFscmVhZHkgb24gdGhlIHN1YmplY3QsIGFz
IHlvdSBzdGF0ZWQsIFNUUyM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7
IGZvbnQtZmFtaWx5OiBhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2
cHg7Ij5oYW5kbGVDb21wbGV0ZSBoYXMgb25seSAyIHBvc3NpYmxlIHN0YXRlcywgc3VjY2VzcyBh
bmQgZmFpbHVyZSwgc28gd2h5IG5vdCBjb21wbGV0ZWx5IHNlcGFyYXRlIHRoZW06PC9zcGFuPjwv
ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U1RTI2hhbmRsZVN1Y2Nlc3MoVCByZXN1bHQsIENhbGxh
YmxlJmx0O1QmZ3Q7IHRhc2sgWywgYm9vbGVhbiBjYW5jZWxsZWRdKTwvZGl2PjxkaXY+U1RTI2hh
bmRsZUZhaWx1cmUoVGhyb3dhYmxlIGV4Y2VwdGlvbiwgQ2FsbGFibGUmbHQ7VCZndDsgdGFzayBb
LCBib29sZWFuIGNhbmNlbGxlZF0pIChub3RlIHRoYXQgd2UgY2FuJ3QgdXNlIHBhcmFtZXRlcml6
ZSBleGNlcHRpb24gaGVyZSk8L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs
IDApOyBmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl
OiAxNnB4OyI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAs
IDAsIDApOyBmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1z
aXplOiAxNnB4OyI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi
KDAsIDAsIDApOyBmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9u
dC1zaXplOiAxNnB4OyI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjog
cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsg
Zm9udC1zaXplOiAxNnB4OyI+WzFdJm5ic3A7PC9zcGFuPmh0dHBzOi8vbWFpbC5vcGVuamRrLm9y
Zy9waXBlcm1haWwvYW1iZXItZGV2LzIwMjMtTWFyY2gvMDA3ODU4Lmh0bWw8L2Rpdj48ZGl2Pjxz
cGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogYXJpYWwsIGhlbHZl
dGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNnB4OyI+PGJyPjwvc3Bhbj48L2Rpdj4=" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0"></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 14, 2023 at 7:30 PM <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><div><br></div><hr id="m_-5073748024455830370zwchr"><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Holo The Sage Wolf" <<a href="mailto:holo3146@gmail.com" target="_blank">holo3146@gmail.com</a>><br><b>To: </b>"Remi Forax" <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>><br><b>Cc: </b>"Alan Bateman" <<a href="mailto:Alan.Bateman@oracle.com" target="_blank">Alan.Bateman@oracle.com</a>>, "attila kelemen85" <<a href="mailto:attila.kelemen85@gmail.com" target="_blank">attila.kelemen85@gmail.com</a>>, "loom-dev" <<a href="mailto:loom-dev@openjdk.org" target="_blank">loom-dev@openjdk.org</a>><br><b>Sent: </b>Sunday, May 14, 2023 5:11:35 PM<br><b>Subject: </b>Re: STS allows to bypass any checked exceptions<br></blockquote></div><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="auto">I think that generally the fact that the interfaces of j.u.function are built without proper exception parameter pushes the problem, and that a more complete solution is to maybe create j.u.f.exceptionally that contains the "correct" implementations.</div></blockquote><div><br></div><div>There is no proper union types in the Java type system so no way to union several exceptions as one type parameter so even if j.u.f interfaces where parametrized by an exception type, the stream API could not have using them properly.<br></div><div><br></div><div>This is different for STS, for STS you declare the common type of result values upfront when creating the STS so you can also declare the common type of the exceptions too.</div><div>In the detail you also need to single out InterruptedException because otherwise the common supertype should be always Exception.<br></div><div><br></div><div>That's why the equivalent of a Callable for STS should be<br></div><div> interface Invokable<T, E extends Exception> {<br></div><div> T invoke() throws E, InterruptedException;<br></div><div> }<br></div><div><br></div><div>In that case, inside TaskHandle, the method get() becomes<br></div><div> interface TaskHandle<T, E extends Exception> {<br></div><div> enum State { SUCCESS, FAILED, CANCELLED, RUNNING }<br></div><div> State state();<br></div><div> T get() throws E, CancelledException<br></div><div> }<br></div><div><br></div><div>With the CancelledException being thrown either because someone has called STS.shutdown() or because the Invokable throws InterruptedException (via a call to a library by example).</div><div>CancelledException should a runtime exception because the user of STS know if shutdown() can be called (explicitly or implicitly by using the subclasses ShutdownOnXX).<br></div><div><br></div><div>This works great especially if STS.handleComplete() does not a TaskHandle as parameter but another object because handleComplete() is not called with a running task or a cancelled task, so that object only need to represent the union SUCCESS(T value) | FAILED(E exception).</div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="auto"><div dir="auto"></div></div></blockquote><div>regards,</div><div>Rémi<br></div><div><br></div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 14, 2023, 17:43 Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">----- Original Message -----<br>
> From: "Alan Bateman" <<a href="mailto:Alan.Bateman@oracle.com" rel="noreferrer" target="_blank">Alan.Bateman@oracle.com</a>><br>
> To: "attila kelemen85" <<a href="mailto:attila.kelemen85@gmail.com" rel="noreferrer" target="_blank">attila.kelemen85@gmail.com</a>><br>
> Cc: "loom-dev" <<a href="mailto:loom-dev@openjdk.org" rel="noreferrer" target="_blank">loom-dev@openjdk.org</a>><br>
> Sent: Sunday, May 14, 2023 3:14:30 PM<br>
> Subject: Re: STS allows to bypass any checked exceptions<br>
<br>
> On 14/05/2023 11:47, Attila Kelemen wrote:<br>
>> :<br>
>> That is - assuming join is invoked without interruption - my problem<br>
>> with the shown behaviour is that the exception thrown by the<br>
>> `Callable` is discarded and an ISE is thrown instead, so we are losing<br>
>> the original exception which could be used for tracking the issue.<br>
> <br>
> The `get` method is used to get the result of as task that completed<br>
> successfully, it's not discarding anything. But maybe you are arguing to<br>
> stay with Future so that Future::get throws ExecutionException with the<br>
> exception as the cause?<br>
<br>
As Attila said, the API of TaskHandle makes it too easy to discard the exception, and and if the exception rarely happens it will be unnecessary hard to debug.<br>
<br>
I think that TaskHandle.get() throwing ISE if STS.join() is not called before is fine because it's a reproducible scenario, throwing ISE if an exception appears in the callable is not fine because it depends on an external factor.<br>
<br>
I think the typ of the exception should be tracked by the type system, what I've called "exception transparency" in a previous mail,<br>
mainly it means that get() should return the value or throw the exception, the type of the exception, like the type of the value should be a type variable.<br>
<br>
By seeing TaskHandle as a Supplier, we are pushing users to ignore exceptions thrown by the callable.<br>
I would prefer taskHandle::get to be convertible to a Supplier only if the callable does not throw an Exception, otherwise taskHandle::get should be convertible to a Callable.<br>
<br>
> <br>
> -Alan.<br>
<br>
Rémi<br>
</blockquote></div><br></blockquote></div></div></div></blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Holo The Wise Wolf Of Yoitsu</div></div>