Should I never catch exceptions directly when usin...
# arrow
n
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...
s
You should never catch
CancellationException
in Kotlin
k
@simon.vergauwen Using the catchNonFatal() extension method on exceptions fixes this right?
p
.nonFatalOrThrow()
will rethrow anything you shouldn’t really be catching
n
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 :)
s
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.
Beware that
runCatching
also swallows
CancellationException
and doesn't re-throw it.
n
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 🤓)