Cause() behavior has changed #219
Comments
Could you show a complete example to try to reproduce the behaviour that you say, because the current behaviour in the Furthermore, You could continue using the version 0.8.1 instead of master or the latest version while you migrate to the new version. |
Hey, if you run this program it will produce different outputs, depending if you use package main
import (
"fmt"
"log"
"net"
"github.com/pkg/errors"
)
func main() {
// Create client/server pair of connections over abstract Unix sockets.
listener, err := net.Listen("unix", "")
if err != nil {
log.Fatalf("net.Listen(): %v", err)
}
address := listener.Addr().String()
client, err := net.Dial("unix", address)
if err != nil {
log.Fatalf("net.Dial(): %v", err)
}
server, err := listener.Accept()
if err != nil {
log.Fatalf("net.Accept(): %v", err)
}
// Close the server end and try to perform a write with the client.
server.Close()
_, err = client.Write([]byte{1, 2, 3, 4})
// Wrap the error and then get the cause.
err = errors.Wrap(err, "connection failure")
fmt.Printf("%T\n", errors.Cause(err))
} In master you'll get:
while with v0.8.1:
If people use |
|
How about informing users to recommend the use of Similar backward compatibility issues will occur when user-defined error types implement |
This is a frustrating problem. There are places where I'd like to be able to take advantage of the added functionality from the |
Perfect so, I will revert this PR and created a new v0.9.1 tag with the old behaviour |
So the new v0.9.1 is tagged with the previous behaviour https://github.com/pkg/errors/releases/tag/v0.9.1 Thanks a lot for all information and help :) |
Yeah, reverting was the right choice. The There is unfortunately, no way to provide |
Given that this was reverted, does it make sense to mark the |
Deprecating |
Hello,
after merging #215, I got some test failures of code that calls
errors.Cause(err)
whereerr
is returned by some stdlib API: in my caseerr
is returned bynet.Conn.Write()
, anderrors.Cause(err)
used to return anet.OpError
instance, whereas it now returns asyscall.Errno
instance.I understand the reason for the change, but just wanting to highlight this is introduces backward-incompatible behavior, at least for some consumers.
YMMV re fixing this issue. Other people might find it useful to read, if the stumble upon the same regression.
The text was updated successfully, but these errors were encountered: