Regarding use of `NonFatal`. I can understand if you really want to handle `InterrupedException` yo...

# arrow

[Trond Engell]

Regarding use of NonFatal. I can understand if you really want to handle InterrupedException you might want to do that more explicitly, but what about errors that are not listed here (excluding subclasses)? Are they not fatal and to be thrown?

fun NonFatal(t: Throwable): Boolean =
  when (t) {
    is VirtualMachineError, is ThreadDeath, is InterruptedException, is LinkageError -> false
    else -> true
  }

[simon.vergauwen]

Yes, they’re considered non-fatal and will be thrown.

[simon.vergauwen]

It’s used in a different manner. If you use Either.catch these fatal errors won’t be caught, but will continue to propagate.

[simon.vergauwen]

So we use this as a predicate

[Trond Engell]

Ah I see. So I should not use this predicate for non-async error-handling purposes?

[Trond Engell]

I remember seeing the same in Scala, but never really understood its purpose.

[simon.vergauwen]

Yes, it’s very common practice in Scala. And it’s actually good practice to do.
If you’re using Arrow, or Cat in Scala this is already done for you out-of-the-box

[simon.vergauwen]

So you shouldn’t worry about it. If you’re doing a lot of custom try/catch with e: Throwable then it’s a good idea to use this predicate as well.

We typically do the following.

try { 
  donSomething()
} catch(e: Throwable) {
   ifError(e.nonFatalOrThrow())
}

[Trond Engell]

I use something similar for Either:

fun <Result> Either.Companion.fromTry(block: () -> Result): Either<Throwable, Result> =
    try {
        block().right()
    } catch (throwable: Throwable) {
        throwable.nonFatalOrThrow().left()
    }

[Trond Engell]

..as we have not introduced use of coroutines yet.

[Trond Engell]

Does that seem ok? I am just worrying that some Errors might slip through by not being thrown, like custom ones introduced by libraries or similar.

[simon.vergauwen]

That’s perfect, and it’ll catch all exceptions except for “is VirtualMachineError, is ThreadDeath, is InterruptedException, is LinkageError”.
Also custom onces introduced by libraries.

[Trond Engell]

So you are saying that the custom ones will be catched, not thrown?

[simon.vergauwen]

Don’t you want all NonFatal to be captured in Left<Throwable>?

[simon.vergauwen]

throwable.nonFatalOrThrow() returns a NonFatal exception, or it rethrows if the above predicate matches.

That means that all exceptions, except for VirtualMachineError, ThreadDeath, InterruptedException & LinkageError will be rethrown. All other exceptions will be returned as Left(exception).

[Trond Engell]

Good question! 😄 I was wondering if what I really wanted was Left<Exception> and to throw all Error. In that case the predicate might not match all errors and I must do so manually. I am trying to wrap my head around this and I am unsure if this is good practice. I am sorry if this is not very Arrow-specific.

[simon.vergauwen]

https://www.scala-lang.org/api/current/scala/util/control/NonFatal$.html

[simon.vergauwen]

https://www.reddit.com/r/scala/comments/e85fdz/question_what_happens_when_your_code_catches_an/

[simon.vergauwen]

https://twitter.com/djspiewak/status/1132747098783223809?s=20

[Trond Engell]

Yes, I do not want to catch Error in any way. Just throw them and crash/exit application to avoid bad state. I just figured there must be a reason why the predicate is defined like this

is VirtualMachineError, is ThreadDeath, is InterruptedException, is LinkageError -> false

..and not like this

is Error, is InterruptedException -> false

It must mean that there is some Error that is not considered fatal.

[Trond Engell]

But i will not continue to bore you with such details. Thanks for the help and hope you have an error-free evening!