Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Properly handle InterruptedException #23

Open
dernasherbrezon opened this issue Jul 26, 2021 · 0 comments
Open

Properly handle InterruptedException #23

dernasherbrezon opened this issue Jul 26, 2021 · 0 comments

Comments

@dernasherbrezon
Copy link

The recent change 98159b6 addressed the major issue with InterruptedException. However there are still several things to improve:

  • log InterruptedException is not necessary, since user's code can't resolve it anyhow. Just found in production logs:
null
java.lang.InterruptedException
        at java.base/java.util.concurrent.FutureTask.awaitDone(FutureTask.java:418)
        at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:190)
        at pl.edu.icm.jlargearrays.ConcurrencyUtils.waitForCompletion(ConcurrencyUtils.java:188)
        at org.jtransforms.utils.CommonUtils.cftrec4_th(CommonUtils.java:8985)

Just raising this issue to start discussion and get some feedback. I would fix it in the following manner:

  • do not log InterruptedException at all. I.e. remove Logger.getLogger(CommonUtils.class.getName()).log(Level.SEVERE, null, ex); from everywhere.
  • immediately return on InterruptedException. This would leave input data partially changed. With the current approach the input data might still be partially computed
  • with the 98159b6 the caller can check interrupted flag and abort the computation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant