Skip to content

Properly handle InterruptedException #23

@dernasherbrezon

Description

@dernasherbrezon

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions