Should ExitCase be deprecated?

[kyay10]

ExitCase is isomorphic to Throwable?. While it does provide some nice names, it can increase friction with using ResourceScope. Also, Failure's constructor is exposed, which is bad because one can construct a Failure that contains a CancellationException

[nomisRev]

I've been wondering that for a while. Whilst it is isomorphic it does add exhaustiveness which forces you to always explicitly think about cancellation. I am okay with removing it, Throwable? indeed has less friction and seems what Kotlin(X) would do.

Great point about Failure's constructor!

[kyay10]

I think it's fine to keep for now. However, I'll open an issue to address Failure() being exposed

[nomisRev]

Hey @kyay10, I'm actually open to getting rid of the ExitCase.

Dealing with CancellationException should not feel foreign in Kotlin.

Side-note: if we do, do we need a nicer and more clear predicate for Throwable to deal with non fatal exceptions that works nice with if guards.

when(exception) {
    null ->
    CancellationException -> 
    else if exception.isFatal() ->
    else -> 
}

The current e.nonFatalOrThrow() and NonFatal(e) are not very use friendly..

[kyay10]

With some abuse of operators, we can do:

when(exception) {
  null ->
  is CancellationException ->
  in FatalExceptions ->
  else ->
}
object FatalExceptions {
  operator fun contains(exception: Throwable) = !NonFatal(exception)
}