358
Sublinks Aims to Be a Drop-In Replacement for Lemmy
(wedistribute.org)
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
The difference being where you handle the error?
It sounds to me like Java works in kinda the same way. You either use
throws Exception
and require the caller to handle the exception when it occurs, or you handle it yourself and return whatever makes sense when that happens (or whatever you want to do before you do a return). The main difference being how the error is delivered.Java has class similar to Result called Optional.
Yeah I suppose ignoring unchecked exceptions, it's pretty similar situation, although the guarantees are a bit stronger in Rust IMO as the fallibility is always in the function signature.
Ergonomically I personally like Result more than exceptions. You can work with it like with any other enum including things like
result.ok()
which gives you Option. (similar to javaOptional
I think) There is some syntactic sugar like the?
operator, that will just let you bubble the error up the stack (assuming the return type of the function is also Result) - ie:maybe_do_something()?
. But it really is just Enum, so you can do Enum-y things with it:In that sense it's very similar to java's Optional if it could also carry the Exception value and if it was mandatory for any fallible function.
Also (this is besides the point) Result in Rust is just compile-time "zero cost" abstraction. It does not actually compile to any code in the binary. I'm not familiar with Java, but I think at least the unchecked exceptions introduce runtime cost?