Is the standard for a function that can raise an e...

# arrow

[dave08]

Is the standard for a function that can raise an error but not return anything to use Either<ErrorType, Unit> as the return type? (When context receivers land, it'll probably be better, but for now...). Maybe an Option<ErrorType> makes more sense?

[simon.vergauwen]

Either<ErrorType, Unit> is very common for this, and is why

[simon.vergauwen]

people have build the Detekt checker.

Option<ErrorType> is also used, although more uncommon sometimes it's the preferred API. Typically that is the case for optional error handling.

Raise would of course make most sense, since it can never be forgotten to be bound.

[dave08]

optional error handling

Isn't that my case?

[dave08]

I don't see why Either<ErrorType, Unit> would be better to represent whether there was an error or not... isn't that really what Option would be representing here?

[simon.vergauwen]

Well, I missed that what I meant with optional error handling is that the missing the error (not calling bind) is a valid use-case

[dave08]

I think what you mean is that Detekt will show when you forget to call bind on Either, but not on Option? I guess I was looking at the function's signature more... since Either<..., Unit> is a bit less clear than Option<ErrorType> in saying that this function can return an error, but you're right, if one forgets that bind() then... I wonder if a val someFun = effect {...} would be better, but then you could forget the () 😂

[dave08]

Wow, context receivers will be a game changer with all this... 🚀

[simon.vergauwen]

No, that's not what I meant. What I meant is that for me Option<ErrorType> is a good option, if you only want to be able to "inspect" the error, but don't want it to short-circuit your logic. Which doesn't seem what you want.

What I would currently do, not sure if possible, is use Raise as an extension receiver. It's not always possible, though but if possible that's what I do now. (Typically it's a private function).

[dave08]

Yeah, well I still have classes around for my use-cases... with dependencies... so it wouldn't be too nice at the call site.

[simon.vergauwen]

I have them as private functions inside classes 😄 I do exactly the same, let me share an example.
https://github.com/nomisRev/ktor-arrow-example/blob/147b8642fbb2f8c351436ff213610b[…]334/src/main/kotlin/io/github/nomisrev/service/SlugGenerator.kt

Here it's for a slightly different reason, because I wanted to use tailrec which is not possible with Either in the return type 😉
It's just simple private class method, so it's not exposed to the rest of the codebase, so I think that's perfect!

TBH, I might still do this if applicable when context receivers arrive. Prefer simpler solution where possible applies here a bit I guess

[dave08]

Yeah, that's a good point ❤️! When you start using Either, you tend to just do everything like that... here's another potential entry in the docs "cookbook"!