Or have checked exceptions (Java). Granted this comes with big downer... If you need to extend functionality and new (updated) code has to throw new exception, your method signature changes :(

But the best so far method I know.

▲

baq 4 days ago | parent [-]

Checked exceptions are not very different from the Result type in that regard TBH.

▲

malkia 4 days ago | parent [-]

As in the caller would be forced/know what to handle in advance? Is this really the case (I'm not sure) - e.g. you call something and it returns Result<T, E> but does it really enforce it... What about errors (results) that came from deeper?

I'm not trying to defend exceptions, nor checked ones, just trying to point out that I don't think they are the same.

For all intent and purposes I really liked Common Lisp's exception handling, in my opinion the perfect one ("restartable"), but it also comes with lots of runtime efficiency (and possibly other) cost (interoperability? safety (nowadays)...) - but it was valiant effort to make programmer better - e.g. iterate while developing, and while it's throwing exceptions at you, you keep writing/updating the code (while it's running), etc - probably not something modern day SRE/devops would want (heh "who taught live updating of code of running system is great idea :)" - I still do, but I can see someone from devops frowning - "This is not the version I've pushed"...)

	▲	vlovich123 4 days ago \| parent [-]
		> but does it really enforce it It warns you if you ignore handling a Result because the type is annotated with must_use (which can be a compile error in CI if you choose to enforce 0 warnings). Not that this is true with try/catch - no one forces you to actually do anything with the error. > What about errors (results) that came from deeper? Same as with exceptions - either you handle it or propagate it up or ignore it.