Comment by thinkharderdev

Comment by thinkharderdev 9 days ago

Very true, but I do think there is an issue in the margin about how easy it is to ignore errors. For example, in Java you might have something like

``` void checkPermissions() throws AuthException ```

so you have to actively ignore errors by catching the exception. Likewise in Rust you can do

``` fn check_permissions() -> Result<(),AuthError> ```

In that case you can just use the `?` operator to short-circuit (and clippy will warn you if your forget to do that).

In other words, while language design can't fully prevent you from ignoring precondition checks, it can make it harder to forget or even force you to actively ignore precondition failures

randomdata 9 days ago

But isn't the idiomatic Go solution something like this?

    func checkPermissions(success func())

Like anything, you can still screw it up if you try hard enough, but it should nudge most in the right direction. The talk of error handling seems like a distraction or a case of someone confusingly trying to write code in another language using Go syntax.

Obviously you are not forced to think of the user when designing an API, but you don't have to be mindful of the user in any language. Not even Haskell can save a developer who doesn't care, as noted in an earlier comment.

Reply View 0 replies

foldr 9 days ago

Go linters do a pretty good job of spotting where error return values have been ignored, so I'd suggest that the kind of bug the OP is referring to is pretty unlikely to happen in a Go project that's properly configured.

Reply View 10 replies

Smaug123 9 days ago

Sure - my question is "why do you need to set up the third party linters when they're so critical to the correctness of your program" really. It's the general "yeah we'll give you these footguns which are the first thing every developer will learn about during their first incident; good luck, and I hope you know you need to do things this way!" attitude I object to.

Reply View | 9 replies
- randomdata 9 days ago
  
  > my question is "why do you need to set up the third party linters when they're so critical to the correctness of your program" really.
  No doubt the same reason it is also critical in Haskell (see comment about isLoggedIn function): Developers not knowing what they are doing.
  If you work within the idioms and generally accepted programming practices this isn't a problem. It only becomes a problem when you get a developer who wants to "go their own way" without understanding why the norms exist. The linter is a crutch to support their "bad habits".
  
  Reply View | 0 replies
- foldr 9 days ago
  
  There’s no simple solution when it comes to ignoring errors. Some errors should be ignored and some shouldn’t. So your only lines of defense are linting heuristics and tests.
  I would agree that languages which handle errors via exceptions have an advantage here, as they make not ignoring errors the default behavior. But even then, it’s obviously still possible to indicate error conditions of various kinds via return values, in which case they can still be ignored thoughtlessly. (And you also have all the bugs caused by unhandled exceptions to deal with.)
  
  Reply View | 6 replies
  
  randomdata 8 days ago
  
  > Some errors should be ignored and some shouldn’t.
  Assuming the function author followed Go conventions, you never need to consider the error for the sake of using the function. Granted, there are some bad developers out there who will do something strange that will come to bite you, but that is not limited to errors (or any particular language).
  You may still need the error for your own application requirements, but application requirements are pretty hard to forget. At very least, you are going to notice that your application is missing a whole entire feature as soon as you start using it.
  
  Reply View | 5 replies
- [removed] 9 days ago
  
  [deleted]
  
  Reply View | 0 replies