5 ms·

Personally I really dislike exceptions and try/catch in languages. I don't like having to worry about whether some function call is going to surprise me with an

Personally I really dislike exceptions and try/catch in languages. I don't like having to worry about whether some function call is going to surprise me with an exception, and handling them with try/catch really breaks the flow of the program. I'm sure there's probably a lot I can learn to make this better for myself because I don't work with exception heavy code very often, but I find working with simple error value returns like in Go or error types in Haskell/Rust to be so much more ergonomic and comfortable to work with.

planet-and-halo 5y ago
I think the biggest place where it's really necessary is integration points. Within your system it's reasonable to try to define exceptions out of existence. Once you start accepting user input or depending upon some system outside of your control, though, you better have some kind of mechanism to handle whatever unknown asteroids come flying in from deep space ready to annihilate your entire planet and civilization.
- gizmo686 5y ago
  That is still provided by error values or error types. The defining feature of exceptions is that they provide a secondary control flow path, and that control flow path automatically flows up the stack until it reaches an explicit catch. With error values/types, control flow happens normally, and the programmer is expected to explicitly branch on the the value using normal control flow constructs.
rgharris 5y ago
Error handling in Go is simple and verbose at the same time. Working in it alongside Python and JavaScript makes me rethink a lot of patterns I’m accustomed to - it’s a nice exercise. Though of course the use cases often vary significantly between the 3 languages so it is tough to even compare.
hackinthebochs 5y ago
The benefit of exceptions and try/catch is that it lets you separate your exception handling logic from the mainline logic of the function. Having error logic weaved in and out of mainline logic just obscures what is going on and increases cognitive load. I much prefer writing and reading code with exceptions than explicit error handling control flow.
- mindwok 5y ago
  Interesting, thanks for sharing. I find there to be more cognitive load with the separate control flow. Different strokes I guess!
- initplus 5y ago
  The challenge with exceptions is there is zero indication at the call site that a function can throw. Does myFunc() throw? Only way to know is to dig down through the entire call stack. Meanwhile with (value, error)/Result etc. it's obvious right at the call site whether a function can potentially error or not.
  - _ZeD_ 5y ago
    It's the exact opposite With the either functional approach you just move the error around, and when you can't deal with it anymore you don't even have the stacktrace to know what damn piece of code created the error in the first place
  - fauigerzigerk 5y ago
    >The challenge with exceptions is there is zero indication at the call site that a function can throw. Swift has that. Calling a potentially throwing function requires that you put "try" in front of it. The downside is that you don't know what it throws (similar to Rust functions returning dyn Error)
  - MattPalmer1086 5y ago
    Java has checked exceptions, but everyone seems to hate them.
throw_m239339 5y ago
Why do people praise Go when it comes to error handling? It's the worst of both worlds since its std libs returns errors sure, but anything can panic as well, which is basically a poor's man exception system. Rust on the other hand, like many other things got it mostly right. If you're going to use errors as a values then you need some constructs to deal with that at the language level. Go's solution isn't more sophisticated than C error codes.
- comex 5y ago
  Rust also has panics as a separate feature from errors-as-values, same as Go…
- mindwok 5y ago
  That's not exactly true. There's very few cases where the standard library will panic, and the handful of cases where it does is for programming errors (like passing a non-nil, zero length buffer into io.CopyBuffer).
jessikat 5y ago
I see a lot of exceptions versus error types/values, as if there's no in-between of exceptions and error types/values. There exist languages that support both. OCaml has both optional values and exceptions. C++ with std::expected. C# with the work on nullability/nullable reference types, and already with nullable value types.

planet-and-halo 5y ago

I think the biggest place where it's really necessary is integration points. Within your system it's reasonable to try to define exceptions out of existence. Once you start accepting user input or depending upon some system outside of your control, though, you better have some kind of mechanism to handle whatever unknown asteroids come flying in from deep space ready to annihilate your entire planet and civilization.

gizmo686 5y ago
That is still provided by error values or error types. The defining feature of exceptions is that they provide a secondary control flow path, and that control flow path automatically flows up the stack until it reaches an explicit catch. With error values/types, control flow happens normally, and the programmer is expected to explicitly branch on the the value using normal control flow constructs.

rgharris 5y ago

Error handling in Go is simple and verbose at the same time. Working in it alongside Python and JavaScript makes me rethink a lot of patterns I’m accustomed to - it’s a nice exercise. Though of course the use cases often vary significantly between the 3 languages so it is tough to even compare.

hackinthebochs 5y ago

The benefit of exceptions and try/catch is that it lets you separate your exception handling logic from the mainline logic of the function. Having error logic weaved in and out of mainline logic just obscures what is going on and increases cognitive load. I much prefer writing and reading code with exceptions than explicit error handling control flow.

mindwok 5y ago
Interesting, thanks for sharing. I find there to be more cognitive load with the separate control flow. Different strokes I guess!
initplus 5y ago
The challenge with exceptions is there is zero indication at the call site that a function can throw. Does myFunc() throw? Only way to know is to dig down through the entire call stack. Meanwhile with (value, error)/Result etc. it's obvious right at the call site whether a function can potentially error or not.
- _ZeD_ 5y ago
  It's the exact opposite With the either functional approach you just move the error around, and when you can't deal with it anymore you don't even have the stacktrace to know what damn piece of code created the error in the first place
- fauigerzigerk 5y ago
  >The challenge with exceptions is there is zero indication at the call site that a function can throw. Swift has that. Calling a potentially throwing function requires that you put "try" in front of it. The downside is that you don't know what it throws (similar to Rust functions returning dyn Error)
- MattPalmer1086 5y ago
  Java has checked exceptions, but everyone seems to hate them.

throw_m239339 5y ago

Why do people praise Go when it comes to error handling? It's the worst of both worlds since its std libs returns errors sure, but anything can panic as well, which is basically a poor's man exception system. Rust on the other hand, like many other things got it mostly right. If you're going to use errors as a values then you need some constructs to deal with that at the language level. Go's solution isn't more sophisticated than C error codes.

comex 5y ago
Rust also has panics as a separate feature from errors-as-values, same as Go…
mindwok 5y ago
That's not exactly true. There's very few cases where the standard library will panic, and the handful of cases where it does is for programming errors (like passing a non-nil, zero length buffer into io.CopyBuffer).

jessikat 5y ago

I see a lot of exceptions versus error types/values, as if there's no in-between of exceptions and error types/values. There exist languages that support both. OCaml has both optional values and exceptions. C++ with std::expected. C# with the work on nullability/nullable reference types, and already with nullable value types.