A modern programming language that makes developers happier.

kotlinlang

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?)

Like this:
```private fun ApplicationCall.getFormParameters() = effect { catch({ receiveParameters() }) { e -&gt; 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)

In this case I'd expect `getFormParameters` to return an `Either`, is the outer `effect{}` necessary?

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

&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 ?: "")) } }```

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?)

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`.

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.

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.

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).