Hi, why `InterruptedException` is considered as fa...
# arrow-meta
d
Hi, why
InterruptedException
is considered as fatal? Found this in
arrow.core.NonFatal
Copy code
fun NonFatal(t: Throwable): Boolean =
  when (t) {
    is VirtualMachineError, is ThreadDeath, is InterruptedException, is LinkageError -> false
    else -> true
  }
i
This is probably better to ask in #arrow-kt, because this function is used in Arrow-Fx or in
Try
, but
Try
is deprecated. Maybe @pakoito or @simon.vergauwen can help.
p
yes, otherwise cancelled threads may have issues. This is lifted from other libraries in Scala IIRC
d
So the reason is that the InterruptedExcption needs special “care” -> when it is caught current thread has to be interrupted again.
My team is working on a service that processes data from Kafka topic and then writes new message to Azure queue. Azure client may throw InterruptedException. Any exception thrown in KafkaStreams kills a stream. So there is a risk that InterruptedExcption will kill our process.
Is there any pattern for handling InterruptedExcpetions that may be throws from code that is called from functional code/scope?
We are trying functional approach but almost everything in JVM a world may end up with exception. Most of the libraries handle errors via exception. Our approach is to wrap every such call in our version of deprecated Try. But now it turns out that we need special treatment for InterrupedException. @pakoito How to live that?
I did some research. I misunderstood the meaning of InterruptedException. In most cases it should be passed higher up in the call stack. Good explanation - https://www.ibm.com/developerworks/library/j-jtp05236/