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.
We currently use https://github.com/michaelbull/kotlin-result , which officially should work on KMP, but has some issues.
// log exception
You either have the case that tech moves on and the LLM is out of date on anything new, so adoption slows or you have tech slowing down because it doesn't work with LLMs so innovation slows.
Either way, it's great if you're working on legacy in known technologies, but anything new and you have issues.
Can I write a spec or doc or add some context MCP? Sure, but these are bandaids.
This also means that exceptions can have stacktraces that only incur a cost on the unhappy path and even only if that exception is uncaught. While if you want a trace for a bad Result you are going to be doing a lot of extra book-keeping that will be thrown away
In general I agree that Results are the better abstraction, but there are sadly some tradeoffs that seem to be hard to overcome.
But more generally the happy-path/error-path distinction can be a bit murky. From my days writing Java back in the day it was very common to see code where checked exceptions were used as a sort of control flow mechanism, so you end up using the slow path relatively frequently because it was just how you handled certain expected conditions that were arbitrarily designated as "exceptions". The idea behind Result types to me is just that recoverable, expected errors are part of the program's control flow and should be handled through normal code and not some side-channel. Exceptions/panics should be used only for actually exceptional conditions (programming errors which break some expected invariant of the system) and immediately terminate the unit of work that experienced the 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)Both snippets suffer from being too limited. The first, as you point out, catches too many exceptions. But the second.... What happens if the email address is taken? That's hardly exceptional, but it's an exception that the caller has to handle. Your natural response might be to check if the email address is taken before calling register, but that's just a race condition now. So you really need a result-returning function, or to catch some (but probably not all) of the possible exceptions from the method.