Home/ Questions/Q 9139761
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T09:25:47+00:00

I understand that there wasn’t much of a choice when InterruptedIOException was introduced; it

  • 0

I understand that there wasn’t much of a choice when InterruptedIOException was introduced; it had to be a subclass of IOException.

The sole existence of InterruptedIOException doubtlessly is making life a bit complicated if you want to know whether a thread was interrupted or not. That’s because you have to treat InterruptedIOException differently from IOException if you want to maintain the information that the thread got interrupted.

While InterruptedIOException was invented for java.nio, there are reports that at least under Solaris, there are java.io methods which throw InterruptedIOException. Also, with a new Android version, one is at risk that a library migrates from java.io to java.nio or additional methods get somehow mapped.

I tend to think one should account for InterruptedIOException to be on the safe side. How do you see it? Insights, experiences, strategies?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Personally I wouldn’t use interrupt if you can avoid it. For blocking IO operations I would set a volatile flag and close the stream instead. If the closed flag has been set I ignore any IOException thrown. This give you more control over how a component is shutdown. Once I set a component to closed I don’t unset of course and I can check this as often as I like.

    • 0