https://kotlinlang.org logo
#arrow
Title
# arrow
d

dave08

03/13/2023, 4:58 PM
I'm trying to seperate this into a function outside the
effect { }
block processing the request:
Copy code
val formParameters =
    catch({ call.receiveParameters() }) { e -> raise(GenericRequestFailure(e.message ?: "")) }
but I can't since I don't have a Raise<> context (and I need the ApplicationCall as the receiver), do I just have to create another effect { } block for it and then use
bind()
or is there a better way? It seems like
Either.catch...
is deprecated... (and doesn't have a raise function?)
Like this:
Copy code
private fun ApplicationCall.getFormParameters() = effect { catch({ receiveParameters() }) { e -> raise(GenericRequestFailure(e.message ?: "")) } }
Is there something I can directly just catch with? Instead of having to surround it with effect { }? (also preferably not having to call bind() on this)
p

phldavies

03/13/2023, 5:31 PM
In this case I'd expect
getFormParameters
to return an
Either
, is the outer
effect{}
necessary?
You can use Either.catch
d

dave08

03/14/2023, 2:49 AM
It's not necessary to use effect, but maybe better than either to avoid wrapping success cases? And Either.catch isn't deprecated?
s

simon.vergauwen

03/14/2023, 7:54 AM
Either.catch isn't deprecated?
No,
Either
is not deprecated and neither is
Either.catch
some redundant variations of
catch
are being deprecated in favor of the composition of their smaller parts. The
catch
function you show in your example is available on `alpha`:
Copy code
private fun ApplicationCall.getFormParameters() = effect { catch({ receiveParameters() }) { e -> raise(GenericRequestFailure(e.message ?: "")) } }
You can do the same with
Either.catch
Copy code
private fun ApplicationCall.getFormParameters() = Either.catch { receiveParameters() }.mapLeft { e -> GenericRequestFailure(e.message ?: "") }
Or in DSL form:
Copy code
private fun ApplicationCall.getFormParameters() = either { catch({ receiveParameters() }) { e -> raise(GenericRequestFailure(e.message ?: "")) } }
d

dave08

03/14/2023, 2:55 PM
Thanks! I was kinda expecting the Either.catch to have the same syntax of the one inside the Raise scope... maybe that was deprecated? Also, wondering if it would make sense to have Effect.catch? I started using Effect more often to avoid extra allocations for each successful result (if I'm right, Either would have to wrap to Right, whereas effect wouldn't? Or maybe I'm not gaining anything because it has to create a lambda every time?)
s

simon.vergauwen

03/14/2023, 2:57 PM
I've thought about that but
Effect
is not a type anymore, so it can also not have a
companion
😅 So there is not a clear place to define
Effect.catch
.
That being said, I wouldn't worry too much about the allocation it's for sure neglect-able in production code. Unless you're in som hot-loops.
d

dave08

03/14/2023, 2:59 PM
But it IS more efficient, no?
s

simon.vergauwen

03/14/2023, 3:05 PM
It should be because allocating a lambda should be more efficient, and
Continuation
lambdas are optimised by the compiler and hotspot should optimise it as well but that contains a lot of should and also heavily depends on the rest of the codebase and usage. (i.e. hotspot optimises based on what is actually happening at runtime). IMO you should do what makes most sense for you, your codebase and team and not worry about these super tiny micro-optimisations unless maybe if you're building a framework or low-level library.
p

phldavies

03/14/2023, 3:20 PM
Optimize first and foremost for readability, don't worry about runtime performance and overheads unless it's likely to be an issue (or can be addressed and still be clear and concise).
3 Views