Should I never catch exceptions directly when using `Raise<E>` ? I've just caught `Cancellatio...

# arrow

[Norbi]

Should I never catch exceptions directly when using Raise<E> ?
I've just caught CancellationExceptionNoTrace which seems to be an implementation detail of the raise mechanism...

[simon.vergauwen]

You should never catch CancellationException in Kotlin

[Kristian Nedrevold]

@simon.vergauwen Using the catchNonFatal() extension method on exceptions fixes this right?

[phldavies]

.nonFatalOrThrow() will rethrow anything you shouldn’t really be catching

[Norbi]

You should never catch CancellationException in Kotlin

Sure, I do it very rarely, eg. when intentionally catching a TimeoutCancellationException.
What I forgot was that the raise mechanism is also implemented using coroutines - sorry for the dumb question 😕 🙂

.nonFatalOrThrow()

Thanks, I have to le-learn many things to get used to the "Kotlin/FP" thinking :)

[simon.vergauwen]

Not sure if it's really related to Kotlin/FP, you shouldn't have to re-learn anything 🤞

If you use catch or Either.catch then you don't have to care about nonFatalOrThrow(). If you're using try/catch it might be interesting to use yourself instead of manually checking if(e is CancellationException) throw e.

I personally prefer withTimeoutOrNull instead of withTimeout and try/catch(e: TimeoutCancellationException) btw.

[simon.vergauwen]

Beware that runCatching also swallows CancellationException and doesn't re-throw it.

[Norbi]

Thanks, I will check out these functions.
(Sorry, I'm new to Arrow as well, so I will surely have some noob questions in the future 🤓)