Exceptions should be reserved for developer errors like edge cases that haven’t been considered or invalid bounds which mistakenly went unchecked.

    fun register(registrationRequest: UserRegistrationRequest): UserDTO {
        return success(registrationRequest)
            .flatMap { validRequest ->
                throwIfExists(validRequest.email) { authService.userExists(validRequest.email) }
            }.flatMap {
                runWithSafety { authService.register(registrationRequest.email, registrationRequest.password) }
            }.getOrThrow()
    }

We have a pretty standard Spring Boot server with the usual reactive kotlin suspend controllers. Our api client is different. We were early adopters of kotlin-js on our frontend. Not something I necessarily recommend but through circumstances it was the right choice for us and it has worked well for us in the last five years. But it was a rough ride especially the first three of those.

As a consequence, our API client is multiplatform. For every API endpoint, there's a suspend function in the client library. And it returns a Result<T> where T is the deserialized object (via kotlinx serialization, which is multiplatform).

On the client side, consuming a result object is similar to dealing with promises. It even has a fold function that takes a success and error block. Basically failures fall into three groups: 1) failures (any 4xx code) that probably indicate client side bugs related to validation or things that at least need to be handled (show a message to the user), 2) internal server errors (500) that need to be fixed on the server, and 3) intermittent failures (e.g. 502, 503) which usually means: wait, try again, and hope the problem goes away.

What I like about Result is making the error handling explicit. But it feels a bit weird to client side construct an Exception only to stuff it into a Result.error(...) instead of actually throwing it. IMHO there's a bit of language friction there. I also haven't seen too many public APIs that use Result. But that being said, our multiplatform client works well for our use.

But I can't expose it to Javascript in its current form; which is something I have been considering to do. This is possible with special annotations and would mean our multiplatform client would be usable in normal react/typescript projects and something I could push as an npm. But the fact my functions return a Result makes that a bit awkward. Which is why I'm on the fence about using it a lot.

So, nice as a Kotlin API but good to be aware of portability limitations like that. You would have similar issues exposing Kotlin code like that to Java.

    } catch (exception: Exception) {
      // log exception
      throw exception
    }

You don't need a library implementation of fold (which can be used to implement map/flatmap/etc). Instead, it can be inlined as a tail recursive function (trf). This is better, in my opinion, because there is no function call indirection and the trf will have a name which is more clear than fold, reducing the need for inline comments or inference on the part of the programmer.

I also am not a fan of a globally shared Result class. Ideally, a language has lightweight support for defining sum/union types and pattern matching on them. With Result, you are limited to one happy path and one error path. For many problems, there are multiple successful outputs or multiple failure modes and using Result forces unnecessary nesting which bloats both the code for unpacking and the runtime objects.

In case it's useful for anyone, here is a simple plug-in-play TypeScript version:

```

type Ok<T = void> = T extends undefined ? { ok: true; } : { ok: true; val: T; };

type Err<E extends ResultError = ResultError> = { ok: false; err: E; };

type Result<T = void, E = ResultError> = { ok: true; val: T; } | { ok: false; err: E | ResultError; };

class ResultError extends Error { override name = "ResultError" as const; context?: unknown; constructor (message: string, context?: unknown) { super(message); this.context = context; } }

const ok = <T = void>(val?: T): Ok<T> => ({ ok: true, val: val, } as Ok<T>);

const err = (errType: string, context: unknown = {}): Err<ResultError> => ({ err: new ResultError(errType, context), ok: false, });

```

```

const actionTaker = await op().then(ok).catch(err);

if (result.ok) // handle error

else // use result

```

I will be forever grateful to the developer first introduced to this pattern!

I wish Oracle et al. had the courage to foist this into the standard library, damn the consequences. Whatever unanticipated problems it would (inevitably) create are greatly outweighed by the benefits.

I've written Pair<> about a dozen times as well.

Maybe you could look up the Try monad API (Scala or Vavr works in Java + Kotlin), by using some extra helper methods you can have something probably a little bit lighter to use.

I believe your example would look like the following with the Try monad (in Java):

  public UserDTO register(UserRegistrationRequest registrationRequest) {
    return Try.of(() -> authService.userExists(registrationRequest.email))
      .filter(Objects::isNull, () -> badRequest("user already exists"))
      .map(userId -> authService.register(registrationRequest.email, registrationRequest.password))
      .get();
  }

[0]: https://github.com/supermacro/neverthrow

Similarly, when constructing physical things, it is not uncommon to have something with fewer inputs than outputs. Along with mode configured transfer of input to outputs.

If you fancy that an error could be just a type, not necessarily a Throwable, you might like Result4k - it offers a Result<T,E>

https://github.com/fork-handles/forkhandles/tree/trunk/resul...

disclaimer: I contribute to this.

    // log exception

        try {
            val user = authService.register(registrationRequest.email, registrationRequest.password)

            return user
        } catch (exception: Exception) {
            // log exception
            throw exception
        }

the whole point of the exceptions (and moreso of the unchecked ones) is to be transparent!

if you don't know what to do with an exception do NOT try to handle it

that snippet should just be

    return authService.register(registrationRequest.email, registrationRequest.password)

[0]: https://effect.website/

Because of your inconsistent line-breaks!

Now we need to invent do-notation, higher kinds and typeclasses and this code would be well composable.

I can't wait until they release rich errors and this nonsense with reinventing checked exceptions will finally end.

Non trivial operations have errors when the happy path fails. And with web apps IO can fail anytime, anywhere for any reasons.

Sometimes you want to handle them locally, sometimes globally. The question is how ergonomic it is to handle this all for a variety of use cases.

We keep reinventing the wheel because we insist that our own use cases are “special” and “unique”, but they really aren’t.

Personally, I think Java’s proposal on catching errors in switches, next to ordinary data is the right step forward.

Monads are great. You can do lots of great things in them, but ergonomic they are not. We should avoid polluting our type systems where possible.