Comment by gwd

Comment by gwd 9 days ago

> have error chaining via a `?` operator

Although I do frequently find typing in the boiler plate of _every_ _single_ _error_ a bit of a faff, it does prompt me each time to really think "what if an error really happened here". I'm inclined to think that something like the ? operator makes it much easier to just toss in the ? and not consider the implications of an error.

> even force you to check the error[,] meaning I’m sure there’s plenty of missed error checks in production code

Something the equivalent of "#[must_use]" would certainly be an additional aid, (as would const pointers).

EDIT but one of the tools mentioned in the blog post, golangci-lint, will warn you of unchecked errors.

vlovich123 9 days ago

You’d really like the C community. They like to say things like “although I do find the setfaults annoying, it really makes me think carefully about memory ownership and layout”. The problem is that if you don’t have a consistent way to accomplish a task correctly, something like errors that could happen a nearly every function call, then you’re very likely to make a mistake. Coupled with that, most people ignore testing for error conditions or simulating errors, so the error handling has a very high likelihood of having bugs.

Reply View 4 replies

gwd 8 days ago

> Coupled with that, most people ignore testing for error conditions or simulating errors, so the error handling has a very high likelihood of having bugs.
Er, is Rust any different in that regard? As I said, I tend to think the `?` operator would make that worse, as the error path is so much less visible. In Golang if you don't test your error path, at least it will be listed as having no coverage -- is the same thing true in Rust?

Reply View | 2 replies
- randomdata 8 days ago
  
  The `?` operator is even worse than that as it leaks implementation details by default (the default you are undeniably going to lean on if testing/simulating error cases is more than you can handle), which is going to make someone's life a miserable hell when requirements change in the future.
  But it seems most programmers here are only around for the MVP and are content to let the future of maintaining their garbage be someone else's problem. Which, I expect, is also the fundamental aversion they have to Go, which is trying to create a world where you still want to work on the same codebase in 30 years.
  Not that Go is perfect. It most certainly isn't. But you are going to spend more time obsessing over things that aren't even all that important in practice when your "launch and dash" lifestyle is being threatened.
  
  Reply View | 0 replies
- lenkite 7 days ago
  
  Rust: this `Result` may be an `Err` variant, which should be handled.
  I am not at all a fan of Rust but dissing the `?` operator and the compilers error/warning messages regarding error handling and somehow thinking Go is superior here when its objectively not is "inconsistent with reality"
  
  Reply View | 0 replies
randomdata 8 days ago

> The problem is that if you don’t have a consistent way to accomplish a task correctly
I know of no programming language that provides a consistent way to deal with values correctly, if the venerable if statement (or whatever is equivalent) is not it.
What is this magical fairy language that you speak of or envision?

Reply View | 0 replies