STS allows to bypass any checked exceptions

Alec Petridis alec at xz.ax
Wed May 17 04:25:39 UTC 2023


The asymmetry between exception declaration & handling in TaskHandle#get 
and Callable#call makes it so changes to the throws declaration of a 
method passed to StructuredTaskScope#fork can be inadvertentlyignored 
until they cause a problem at runtime.


If you were a downstream consumer of an interface like

    interface TemperatureSensor {

         double temperature();

    }

and TemperatureSensor#temperature()'s fallibility changed, existing 
non-STS usages of the method would not compile:

    interface TemperatureSensor {

         double temperature() throws I2CException;

    }

    gearboxSensor.temperature(); // compile error: checked exception not
    caught

while existing usages of the method in calls to StructuredTaskScope#fork 
would compile:

    try (var scope = new StructuredTaskScope<>()) {

         var temperatureHandle =
    scope.fork(gearboxTemperatureSensor::temperature);

         // ...

         scope.join();

         if (temperatureHandle.get() > GEARBOX_TEMPERATURE_LIMIT) //
    newly-added checked exception I2CException is not handled

             emergencyStop();

    }


A TaskHandle seems a bit like a nullable value in this regard: it's not 
clear from the declaration point whether a presence check is required 
before the inner value is accessed.


Regards,

Alec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230516/74bf55e1/attachment.htm>


More information about the loom-dev mailing list