What Do You Do with InterruptedException (Java)? (2015)
yegor256.com
yegor256.com
This brought to mind a related problem in Java, which the original article here discusses very well -- "What Do You Do With InterruptedException?". I worked with Java for several years recently at a low-engineering-function place where properly addressing InterruptedException was really really low-priority compared to other problems. So ... only one other team member seemed ready to discuss properly addressing InterruptedException though it was relevant to a lot of our use cases ...
So I'm curious:
* have others worked in environments where InterruptedException
was actually both handled correctly, and proved useful?
* how often have others seen frameworks that demand that you,
as a framework user/extender, properly handle
InterruptedException/Thread.interrupted() because they, i.e.,
the framework, will notify your framework thread to stop
what it's doing via Thread.interrupt()?
* how well to library-code implementers (e.g., code in public
Maven artifacts) adhere to best practices in this area?
As a product developer, or as a framework user, I don't think I'd ever want to exclusively rely on Thread.interrupted()/InterruptException to deal with "canceling" work. Of the 10 to 60 libraries I might typically use that do network I/O, disk I/O, sleep, etc., I don't think I ever could rely on all libraries properly propagating the "interrupted" status back to my own code. And I'd likely not manage to get co-workers to honor and propagate that either. I'd always end up writing own separate "job-status-checker" in worker threads to get them to find out whether they should continue with their work or quit, since there's low-trust with InterruptedException.So ... what's been your experience?
[edits: re-wording, grammar]