Use go error wrapping for easier error handling

[vansante]

This will make it easier for user's of this library (like me :) ) to filter out the different underlying errors and handle them.

For more information, see:

https://blog.golang.org/go1.13-errors

[mholt]

I prefer to not wrap errors unless absolutely necessary, as it adds more to the exported API. Which error values do you need, and where specifically?

[vansante]

For a user API I am writing out archive files directly to an http.ResponseWriter and users of course sometimes break the connection in the middle of the archive, so for my case specifically Id like to see errors like return fmt.Errorf("%s: copying contents: %v", f.Name(), err) wrapped as that is the one that is triggered the most as far as I can see.

However, since the connection break can happen at any time I am sure there are other points the error can occur and it would be nice to have a wrapped error at all those points so I can see whether its an expected error.

I use this function to determine whether to log the error or not (it checks whether its an error caused by a broken connection):

func IsCommonNetworkError(err error) bool {
	// Many disconnects will have this error
	if errors.Is(err, io.ErrUnexpectedEOF) {
		return true
	}

	if errors.Is(err, syscall.ECONNRESET) {	// Connection reset
		return true
	}

	if errors.Is(err, syscall.EPIPE) { // Broken pipe
		return true
	}

	var opError *net.OpError
	if errors.As(err, &opError) {
		// A network error with a timeout or a temporary error
		return opError.Timeout() || opError.Temporary()
	}
	return false
}

[mholt]

I see -- in that case, how about we wrap only the errors where that error can be produced? For example, the copying functions, like this one: https://github.com/mholt/archiver/pull/276/files#diff-eb0dc60e60c8ae25e2a92035d05dd37fce16fbb315eb4b34c8021e29c8f43e38R451

[vansante]

Allright, lets start with those!

PR updated :)

[mholt]

Great, thanks!