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