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