It is a nicer way I think. But other languages do allow for good exception handling. It’s just there’s not a clear cut sign that no-one has handled the exception yet. So often it doesn’t get handled.
What I mean by that is. If I have a function that returns say a string. As a caller, you don’t know whether that function is always going to return a string (it handled exceptions internally), or if it returns a string but might return an exception. So you need to try/catch (or whatever is the equivalent in that language). It’s not clear to the caller.
Whereas with rust, if you’re holding a value wrapped in a result, it means that any exception hasn’t been handled yet. If you’re not passing the value (still inside the result) back to a caller, tag you’re it! :P
It is a nicer way I think. But other languages do allow for good exception handling. It’s just there’s not a clear cut sign that no-one has handled the exception yet. So often it doesn’t get handled.
What I mean by that is. If I have a function that returns say a string. As a caller, you don’t know whether that function is always going to return a string (it handled exceptions internally), or if it returns a string but might return an exception. So you need to try/catch (or whatever is the equivalent in that language). It’s not clear to the caller.
Whereas with rust, if you’re holding a value wrapped in a result, it means that any exception hasn’t been handled yet. If you’re not passing the value (still inside the result) back to a caller, tag you’re it! :P
I like the flexibility Rust offers with the result type. It makes the error handling part of the control flow rather than an afterthought.