https://kotlinlang.org logo
Join Slack
Powered by
To catch an exception the right thing is to use `c...
# arrow
d
To catch an exception the right thing is to use 
client.runCatching { get("/") }.bind()
?
p
I would suggest Either.catch
d
But it returns an 
A
not `R`:
Copy code
public inline fun <R, A> Raise<R>.catch(
  @BuilderInference action: Raise<R>.() -> A,
  @BuilderInference catch: Raise<R>.(Throwable) -> A,
)
p
Oh, I see, I have forgotten the exact syntax
c
Never use kotlin.runCatching with coroutines. They are not compatible.
runCatching
catches 
CancellationException
, which is forbidden by the coroutines library (it breaks structured concurrency). To my knowledge Arrow's 
Either.catch
is fine, but the arrow maintainers can confirm
d
Oh... I just got it:
Copy code
val response = catch({ request() }, { raise(ServerIsDown) })
I had to use 
raise(..)
, it seems like catch is also a recover mechanism if you return a valid right value instead of raising.
p
Indeed, 
Either.catch
uses 
t.nonFatalOrThrow().left()
to capture the thrown 
Throwable
, and rethrow it if it's considered "fatal" (including cancellation) - based on the platform-specific implementation of a NonFatal predicate.
s
it seems like catch is also a recover mechanism if you return a valid right value instead of raising.
Yes, all these APIs are the same. Where 
catch
works over 
Throwable
, and 
recover
over 
E
. 
catch
also exists over a 
reified E
in case you only want to 
catch
specific errors.
It would be nice to have a KDOC on 
catch()
explaining that... it's not really clear from it's name.
Which documentation are you looking at? It's explained in the 
catch
function on 
Either<Throwable, A>
is it missing from the DSL version?
d
Both don't seem to be documented... when discovering a new library one of the first things I do is try 
this.
and see what Idea pulls up, then I press ctrl-q to get the kdocs in a popup window... it's MUCH easier and faster to discover a new api than to go back and forth to the docs site...
If they're both the same, will one be deprecated?
s
If they're both the same, will one be deprecated?
One is DSL version, and one is top-level so both will exists alongside each-other.
d
image.png
image.png
First is in Either, second is in Raise... maybe it was documented after alpha 28?
Or these are overloads?
One is DSL version, and one is top-level so both will exists alongside each-other. (edited)
I see them both in the DSL
s
These are all overloads, but I see only 
recover
is documented and not 
catch
.
Adding 
/** @see catch */
into the KDoc doesn't help since it's ambiguous for overloads and duplicating documentation doesn't seem like a good solution either.
Either.Companion.catch
is indeed undocumented.
d
Maybe some build hook to add the docs before publishing to Maven..? (like maybe if it would process those 
/** @see ...*/
s...)
I wonder if there are others that have this same problem...
since it's ambiguous for overloads
Adding a 
@JvmName
doesn't help there? 🤞🏼
c
No, KDoc links use the Kotlin name
It's on purpose, so overloads appear in a single page in the documentation (this way you can easily see what overloads of the function you're looking at exist, which is very hard in the old Javadoc format)
Since overloads are supposed to do the same thing, they're expected to appear together and it shouldn't matter which one the user is looking at I think you can disambiguate by explicitly adding the receiver if it's different though 🤔
d
But Intellij isn't as smart to know how to pull those all together...
c
It should autocomplete all of them? But indeed, it won't magically add the documentation to ones that aren't documented.
I tend to duplicate a short description of what the function does, then link to the containing class or object where I put the detailed explanation
20 Views
Open in Slack
PreviousNext
Powered by