4 ms·

> I explained why the example is too simple. And I offered a second example with a nested error, and nothing changed. Errors are just enums, there's nothing mo

by kaoD 8y ago

> I explained why the example is too simple. And I offered a second example with a nested error, and nothing changed. Errors are just enums, there's nothing more complex than this. It's that simple. > If you coded this in C with an integer error code the code would also be roughly the same size. But it wouldn't check the error types. It's a zero-cost abstraction. > I can freely change the implementation and if that causes new and different exceptions to be possible, that doesn't affect the implementors. Neither does in my case... unless I care about the actual errors, which I did in this case in main() just for completeness.

wvenable 8y ago
Honestly, that second example is more complex. Now you're had to manually map one error onto another in order to propagate it. How big does MyError get when you have OtherError, AnotherError, FailureNum5, ChokedOnBanana. You're just doing busy work creating types and mapping them together. And this is just a simple toy example! You're quick to hand-wave that wasted effort. What value is the enum value Other(OtherError) actually provide other than to satisfy the compiler? How far do we take this when there are more levels? OtherFailure(OtherMistake(Other(OtherError)))? > Neither does in my case... In each example you changed the implementation of type so that it is no longer compatible. You altered the signature of the method. > But it wouldn't check the error types. It's a zero-cost abstraction. It's funny that you say that as error returns have a non-zero runtime cost. Yet exceptions can actually be zero-cost at runtime (if they aren't thrown) as they can be implemented out of band. Only the most naive implementation propagates exceptions with multi-value returns. Now I do understand why Rust is implemented this way but it's not because error returns are unequivocally better. Good code with exceptions have very little code actually related to error handling. Throw often, catch infrequently, and use normal resource cleanup for exceptional cleanup as well. You can get far with a 2-3 well placed catch statements and that's it. No extra typing. No error propagation code. If you think of error handling as happening where the error is raised as opposed to where it is handled it's hard to see the advantage of exceptions. Where the error is raised is not that important.
- kaoD 8y ago
  I see your point and I will consider it. Thanks for the discussion. What's a language that does exceptions just right for you?
  - wvenable 8y ago
    C#/C++ do exceptions fine. However, it's more useful to point out the language that does exceptions all wrong: Java. I feel like the current anti-exception sentiment is mostly due to programmers first or major experience with exceptions is checked exceptions in Java. If I had to choose between checked exceptions and well typed error propagation, I'd choose the latter hands down. Checked exceptions have all the disadvantages of error returns and none of the advantages. This meshes with my point about where the error concerns are; Java requires you to be very concerned about what errors are thrown at every method definition and call. But C#, which is a very similar language, doesn't. In C#, you only have to be concerned about where and what errors you can handle.

by kaoD 8y ago

wvenable 8y ago

Honestly, that second example is more complex. Now you're had to manually map one error onto another in order to propagate it. How big does MyError get when you have OtherError, AnotherError, FailureNum5, ChokedOnBanana. You're just doing busy work creating types and mapping them together. And this is just a simple toy example! You're quick to hand-wave that wasted effort. What value is the enum value Other(OtherError) actually provide other than to satisfy the compiler? How far do we take this when there are more levels? OtherFailure(OtherMistake(Other(OtherError)))? > Neither does in my case... In each example you changed the implementation of type so that it is no longer compatible. You altered the signature of the method. > But it wouldn't check the error types. It's a zero-cost abstraction. It's funny that you say that as error returns have a non-zero runtime cost. Yet exceptions can actually be zero-cost at runtime (if they aren't thrown) as they can be implemented out of band. Only the most naive implementation propagates exceptions with multi-value returns. Now I do understand why Rust is implemented this way but it's not because error returns are unequivocally better. Good code with exceptions have very little code actually related to error handling. Throw often, catch infrequently, and use normal resource cleanup for exceptional cleanup as well. You can get far with a 2-3 well placed catch statements and that's it. No extra typing. No error propagation code. If you think of error handling as happening where the error is raised as opposed to where it is handled it's hard to see the advantage of exceptions. Where the error is raised is not that important.

kaoD 8y ago
I see your point and I will consider it. Thanks for the discussion. What's a language that does exceptions just right for you?
- wvenable 8y ago
  C#/C++ do exceptions fine. However, it's more useful to point out the language that does exceptions all wrong: Java. I feel like the current anti-exception sentiment is mostly due to programmers first or major experience with exceptions is checked exceptions in Java. If I had to choose between checked exceptions and well typed error propagation, I'd choose the latter hands down. Checked exceptions have all the disadvantages of error returns and none of the advantages. This meshes with my point about where the error concerns are; Java requires you to be very concerned about what errors are thrown at every method definition and call. But C#, which is a very similar language, doesn't. In C#, you only have to be concerned about where and what errors you can handle.