Yeah, at $DAYJOB, we switched (regrettably) from Scala to Kotlin and wanted to continue using the errors-as-value style, which I was the biggest proponent of. However, there not being a way to make the Kotlin compiler shout at you, if you implicitly ignore a return value, really made me question that choice.
It means that if you refactor a function to now be able to fail, then you have to go to all usages and make sure you continue the bubbling.
With exceptions, you should also do that, to potentially introduce try-catches, but if you don’t, then it will at least crash very visibly.
If the compiler does shout at you, like in Scala and Rust, then I think, that’s a better pattern.
Yeah, at $DAYJOB, we switched (regrettably) from Scala to Kotlin and wanted to continue using the errors-as-value style, which I was the biggest proponent of. However, there not being a way to make the Kotlin compiler shout at you, if you implicitly ignore a return value, really made me question that choice.
It means that if you refactor a function to now be able to fail, then you have to go to all usages and make sure you continue the bubbling.
With exceptions, you should also do that, to potentially introduce try-catches, but if you don’t, then it will at least crash very visibly.
If the compiler does shout at you, like in Scala and Rust, then I think, that’s a better pattern.
Especially when you tell the compiler to treat unhandled error types as error instead of warning.