tpietzsch
commented
12 months ago Yes, re-throwing the exception is definitely better than printStackTrace().
In the same method, also ExecutionException is caught and printed. It would be good, to also fix that. Do we know what we potentially expect to be nested under the ExecutionException? Could also be InterruptedException? Anything else? Maybe we can handle and re-throw expected standard causes, and wrap the rest into RuntimeException.
The exceptions will bubble up to the public static labelAllConnectedComponents methods and should also be declared there.
https://github.com/imglib/imglib2-algorithm/blob/2d8ae779fdfac1c77ccc6578d794c2f8121fc938/src/main/java/net/imglib2/algorithm/labeling/ConnectedComponents.java#L494
I have a situation where I expect the user may modify the image I am running ConnectedComponents on, in which case I interrupt the existing attempt and retrigger with the new image. It works fine, but always prints the stack trace from the interrupted exception. I'm not sure how best to handle here, but given this is a blocking and potentially slow task, it may be best to just let the method
throws InterruptedException? Or is there a better way to achieve this?