I m trying to seperate this into a function outside the `eff

Question

I m trying to seperate this into a function outside the `effect ` block processing the request ```val formParameters = catch call receiveParameters e gt raise GenericRequestFailure e message ``` but I can t since I don t have a Raise lt gt 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

dave08 · Answer

Like this ```private fun ApplicationCall getFormParameters = effect catch receiveParameters e gt raise GenericRequestFailure e message ```

dave08 · Answer

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

phldavies · Answer

In this case I d expect `getFormParameters` to return an `Either` is the outer `effect ` necessary

phldavies · Answer

You can use Either catch

dave08 · Answer

It s not necessary to use effect but maybe better than either to avoid wrapping success cases And Either catch isn t deprecated

simon.vergauwen · Answer

gt 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` ```private fun ApplicationCall getFormParameters = effect catch receiveParameters e gt raise GenericRequestFailure e message ``` You can do the same with `Either catch` ``` private fun ApplicationCall getFormParameters = Either catch receiveParameters mapLeft e gt GenericRequestFailure e message ``` Or in DSL form ```private fun ApplicationCall getFormParameters = either catch receiveParameters e gt raise GenericRequestFailure e message ```

dave08 · Answer

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

simon.vergauwen · Answer

I ve thought about that but `Effect` is not a type anymore so it can also not have a `companion` sweat smile So there is not a clear place to define `Effect catch`

simon.vergauwen · Answer

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

dave08 · Answer

But it IS more efficient no

simon.vergauwen · Answer

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

phldavies · Answer

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