I’d rather have exceptions thrown for a simple reason: errors as values make it too easy to ignore them. You have to explicitly check for errors and take a different course of action rather than your program do it for you.
If I’m parsing a JSON and there’s a syntax error, I definitely DO NOT want my program to keep running and risk entering an undefined state because a function somewhere is not checking the error value. An exception forces the consumer of a function to handle it, or have the program fail. The point the article makes about “not being able to tell where the error came from” is bogus since there’s a stack trace.
IME the default behavior of a program when facing an unhandled error should be to stop execution. There are a million things that could go wrong. We can’t cover them all and we shouldn’t expect consumers to check for errors on every line when they might not even be able to handle them: that’s where bubbling up errors really comes in handy. And making it happen when they’re just values require all intermediate functions to check for them.
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.
If you wrote the type signature of
get_userastuple[User, None] | tuple[None, Exception], the assertion would not be necessary and the type checker wouldn’t complain.
