6 ms·

> Rust's advantage is that it forces you to at least pretend to handle the error I'm not sure I would call this an advantage. See: Handling of Checked Except

> Rust's advantage is that it forces you to at least pretend to handle the error I'm not sure I would call this an advantage. See: Handling of Checked Exceptions in Java.

zmmmmm 7y ago
Sort of seems even worse in that there is no built in way to propagate the error if you don't want to handle it. At least with Java you just added the exception to the throws declaration of your function if you didn't want to handle it. Here you have to do something about it or manually do something to propagate it? I think the failure of checked exceptions in Java to be a really interesting example to study for language designers, because on the surface, it seems like it was mostly a good idea. Yet in practice it was nearly universally disliked.
- estebank 7y ago
  When in Java you add a method call with an exception you either handle it or add the method call and the exception type to the list. In Rust when you add a method call that has a Result, you either handle it or add ? to the end of it to propagate the error, auto converting to the appropriate error type. The experience is much better than on Java, while still properly documenting where failures can happen and what isn't being handled.
  - zmmmmm 7y ago
    > you either handle it or add ? to the end of it to propagate the error, auto converting to the appropriate error type But that can only happen if the method returns a type of Result, true? Does this have the effect that just about every function ends up having to return Result (so that the ? operator works)?
    - deleted 7y ago
      [deleted]
    - estebank 7y ago
      Pretty much, which means that the existence of fallible functions is exposed or handled. The big difference with explicit exceptions in Java is that Rust has enums that let you encode every error (so the type checker shows you when you add a new error type where you haven't handled it) so the list of possible errors goes in your enum, not the function definition or alternatively lets you rely on trait objects, which you can't match on but you don't care about when moving them around, which can be equivalent to relying on the root of the an object inheritance tree.
- dragonwriter 7y ago
  > Sort of seems even worse in that there is no built in way to propagate the error if you don't want to handle it. That's better, not worse, because it means you don't up with unhandled downstream errors bloating the signature just because people didn't want to bother with them, which means people are more likely to do something sensible (which may just be wrapping) with them.
dllthomas 7y ago
Checked expressions suffered from a woefully insufficient language to describe what might be thrown. For instance, there was no good way to type a map function.

> Rust's advantage is that it forces you to at least pretend to handle the error I'm not sure I would call this an advantage. See: Handling of Checked Exceptions in Java.

zmmmmm 7y ago

Sort of seems even worse in that there is no built in way to propagate the error if you don't want to handle it. At least with Java you just added the exception to the throws declaration of your function if you didn't want to handle it. Here you have to do something about it or manually do something to propagate it? I think the failure of checked exceptions in Java to be a really interesting example to study for language designers, because on the surface, it seems like it was mostly a good idea. Yet in practice it was nearly universally disliked.

estebank 7y ago
When in Java you add a method call with an exception you either handle it or add the method call and the exception type to the list. In Rust when you add a method call that has a Result, you either handle it or add ? to the end of it to propagate the error, auto converting to the appropriate error type. The experience is much better than on Java, while still properly documenting where failures can happen and what isn't being handled.
- zmmmmm 7y ago
  > you either handle it or add ? to the end of it to propagate the error, auto converting to the appropriate error type But that can only happen if the method returns a type of Result, true? Does this have the effect that just about every function ends up having to return Result (so that the ? operator works)?
  - deleted 7y ago
    [deleted]
  - estebank 7y ago
    Pretty much, which means that the existence of fallible functions is exposed or handled. The big difference with explicit exceptions in Java is that Rust has enums that let you encode every error (so the type checker shows you when you add a new error type where you haven't handled it) so the list of possible errors goes in your enum, not the function definition or alternatively lets you rely on trait objects, which you can't match on but you don't care about when moving them around, which can be equivalent to relying on the root of the an object inheritance tree.
dragonwriter 7y ago
> Sort of seems even worse in that there is no built in way to propagate the error if you don't want to handle it. That's better, not worse, because it means you don't up with unhandled downstream errors bloating the signature just because people didn't want to bother with them, which means people are more likely to do something sensible (which may just be wrapping) with them.

dllthomas 7y ago

Checked expressions suffered from a woefully insufficient language to describe what might be thrown. For instance, there was no good way to type a map function.