return a tls.CertificateVerificationError when verifying the certificate fails

[marten-seemann]

This error was added in Go 1.20.

[marten-seemann]

The question is, how does a reasonable error API look like.
Currently, the TransportError contains an ErrorMessage string:

quic-go/internal/qerr/errors.go

Lines 15 to 20 in 6d7280b

	type TransportError struct {
	Remote bool
	FrameType uint64
	ErrorCode TransportErrorCode
	ErrorMessage string
	}

We could replace this with an Err error, which would allow seamless unwrapping of the error (and users to use standard Go error inspection functions like errors.As). For crypto errors, we'd just set whatever error we get from the TLS stack. For errors that we generate, we'd use fmt.Errorf.

However, this doesn't really make a lot of sense for errors that we receive from the peer. There, we only have the error code and the error message, and wrapping those in a Go error doesn't feel right. I'm wondering if there's a better error abstraction.

[MarcoPolo]

What about a way for an application to define the mapping/func from (errorCode, errorMessage) -> error. Then the application can create distinguished errors for certain error codes and handle them cleanly in their application logic. The fallback case can be a new Go error.

[marten-seemann]

I'm not sure how that would work? The more idiomatic way would be to allow the application to do error assertions / unwrap the underlying error, which is what #4015 does.