Hacker News Reader

Single line reduces noise, but doesn't make it less cumbersome. My pet peeve is that when error types differ, I need to juggle between `err` and `err2`. When I refactor code and add/remove fallible functions, I need to change between `=` and `:=` accordingly only because the error has to get a named variable every time.

Generally, returning a typed error in the function signature in Go is very annoying and dangerous. An example why:

    import "fmt"
    
    type MyError struct{}
    
    func (m *MyError) Error() string {
     return ""
    }

    func myFunc() *MyError {
     return nil
    }
    
    func main() {
     var err error
     err = myFunc()
     if err == nil {
      fmt.Println("No Error")
     } else {
      fmt.Println("Error") // This prints
     }
    }

thats kind of misleading, as you could just do:

    func myFunc() error

Yes you could do that, but then you’d lose type info on the error.

I agree this is awful, but isn't it solved here by not using pointers? I don't remember coming across a case where a custom error type benefited from being a pointer. I am sure such a case exists, but then such a case should be used when giving example code.

No not using pointers would not solve the issue. The issue is that the specific error implementation type is part of the method signature. If you returned type MyError instead of *MyError, then it would be impossible to return nil from the method because only pointers can be nil.

I get that. But why define the Error method on a pointed receiver? In my experience almost all errors can be immutable particularly once you start using wrapping.

Never mind- that doesn't actually make a difference. The solution in this case is to not re-use an existing error variable- but re-use of an error variable is common practice.

Yea, the issue is that nil's in Go are typed. So `err == nil` is checking err against error's nil value, but the value stored in err is *MyError's nil value.

    package main
    
    import "fmt"
    
    type MyError struct{}
    
    func (m *MyError) Error() string {
        return ""
    }
    
    func main() {
        var err error = nil
        var myErr *MyError = nil

        fmt.Println(err == myErr) // this is false
    }

Comparing different types normally is a type error. But for interfaces the non-interface value will be converted to the type of the interface value. This conversion gives it a boxed dynamic type. This is different type than just assigning nil, which is the untyped nil, which sets the interface to its zero value.

Normally one would not compare two interface values, so this issue really comes up when comparing an interface to nil. If Go had proper option types then this issue would go away.

https://go101.org/article/nil.html

package main

import "fmt"

type Err1 struct{}

func (m Err1) Error() string { return "" }

type Err2 struct{}

func (m Err2) Error() string { return "" }

func main() {

  var err error = nil

  var myErr1 *Err1 = nil

  var myErr2 *Err2 = nil

  fmt.Println(err == myErr1)                      // this is false
  fmt.Println(err == myErr2)                      // this is false
  fmt.Println((error)(myErr1) == (error)(myErr2)) // this is false. requires the cast to do the comparison
 }

Couldn't they solve this by letting you rebind/shadow `err` without requiring a new block? Then to make sure you don't accidentally ignore the error, the standard unused variables compile error would prevent that (it would right? it could at least).

This would be easier if there was an easy way to write the zero value, irrespective of type.

https://github.com/golang/go/issues/19642 was a proposal to have e.g.

  return _, _, err

as an alternative to e.g.

  return 0, "", err

I would prefer this to the status quo, but it isn't a completely clean solution to the problem. If I now make a one line change at the bottom of my function to return one additional result, the only additional change in the diff should be to the type signature. But now my diff will still show adding zero values on all the rest of the return lines. It's nice that they will only be underscores- again it is certainly better than the status quo.

> all you want to do is return an error

Nope. This isn't even true in all situations. For a simple example, just look at description of the extremely popular io.Reader:

> An instance of this general case is that a Reader returning a non-zero number of bytes at the end of the input stream may return either err == EOF or err == nil.

https://godocs.io/io#Reader

In 99% of situations you do not check the error type nor the value, like io.Reader.

> I think the biggest problem with error verbosity is just that you have to also return zero values for the success results

I agree, and this got worse with generics since T{} doesn't work, and we have to use *new(T), which is quirky.

However, I wonder if we just want an Optional/Maybe type that has support for multiple values. Without variadic/recursive generics, we'd need compiler support. But a tagged union would get rid of the zero-values.

(I somewhat agree about the io.Reader case where returning both the number of "screwed up" bytes and an error can be useful, though perhaps the number of bytes should be encoded in the error type instead. I rarely care about them.)

> (I somewhat agree about the io.Reader case where returning both the number of "screwed up" bytes and an error can be useful, though perhaps the number of bytes should be encoded in the error type instead. I rarely care about them.)

Or you can just keep it as-is because it's one of the very few cases where it does make sense to have a product type.

Well if you add sugar for errors, and as sugary as "specific to the error type as the last element of a return type, plus automatic zero values", then just make it like rust's `?` already.