okay I seee : ```fun NonFatal(t: Throwable): Boole...

# arrow

[Satyam Agarwal]

okay I seee :

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

[raulraja]

In general you should avoid capturing Throwables listed there because you have no guarantees the VM is in a state that you can do anything about it

[raulraja]

so those should propagate upstream most likely toward a crash in most cases

[Satyam Agarwal]

Okay. Was just curious as I got raiseNonFatal in the dropdown list in IntelliJ.

[raulraja]

yes, if you are gonna raise a Throwable that you don’t know what kind it is the safe path is NonFatal

[raulraja]

also that is gonna change because instantiating a Throwable itself is an effect

[raulraja]

it call into fillInStackTrace which is a native slow op to gather the stack frames info

[raulraja]

which means that anything related to throwable moves to Arrow Fx and just suspend

[Satyam Agarwal]

okay. Do you think this approach would still cahh fillInStackTrace :

sealed class DomainError : Throwable() {
    object AuthenticationTokenInvalid : DomainError()
    object AuthenticationTokenUnavailable : DomainError()
    object DatabaseFatalError : DomainError()
    object NotFound : DomainError()
}

and then for example :

myIO.handleErrorWith { e ->
    when (e) {
        is ClientRequestException -> DatabaseFatalError.raiseError()
        else -> NotFound.raiseError()
    }
}

[Satyam Agarwal]

You gave me once a link to a bolg post about fillInStackTrace, so did a little reading. What I understood was, if I can use static exceptions, then it can get away without doing this expensive op. But I am not sure.

[raulraja]

you need to override fillInStackTrace in DomainError and return yourself

[raulraja]

it’s what the Throwable constructor calls

[Satyam Agarwal]

nice, Thanks 🙂