


Why do I only receive the 'errors.As should not be *error' build error for the second parameter in my tests?
php editor Zimo, hello! Regarding the problem in the build error you mentioned, there may be several reasons for the "errors.As should not be error" error. First, this error usually means that the wrong second argument was used during the build. You need to make sure the second parameter is correct and matches the required type. Secondly, it could be that you are using the wrong data in your test. Please review your test data carefully and make sure they meet the expected format and requirements. Finally, this error can also be caused by issues with the framework or library. In this case, it is recommended to consult the relevant documentation or seek help from the community to find a solution. Hope these tips are helpful!
Question content
Consider the following test:
import ( "errors" "fmt" "testing" ) func testerror(t *testing.t) { err := &myerror{} var target error fmt.println(errors.as(err, &target)) } type myerror struct{} func (err *myerror) error() string { return "oops!" }
Running this test will return the build error second parameter to the error. Should not be *error
.
Go to the amusement park
However, when running the exact same code in main
, the program runs without issue:
package main import ( "errors" "fmt" ) func main() { err := &myerror{} var target error fmt.println(errors.as(err, &target)) } type myerror struct{} func (err *myerror) error() string { return "oops!" }
Go to the amusement park
I'm seeing this behavior in the go playground and in my local development environment, both using go 1.20.
Is this a bug in go?
edit
I was able to solve the build failure issue in the test by creating the error
type:
package main import ( "errors" "fmt" "testing" ) type Error error // <===== Add error type func TestError(t *testing.T) { err := &MyError{} var target Error // <===== Use Error type fmt.Println(errors.As(err, &target)) } type MyError struct{} func (err *MyError) Error() string { return "oops!" }
Solution
This error was reported by the go vet
command. The go test
command automatically runs go vet
to report critical issues. The go build
command does not run the go vet
command.
This warning is not a bug in Go.
Calling errors.As
with *error as the second argument makes no sense, since you already know that the first argument satisfies the error
interface. You're almost certainly doing something wrong.
The above is the detailed content of Why do I only receive the 'errors.As should not be *error' build error for the second parameter in my tests?. For more information, please follow other related articles on the PHP Chinese website!

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics



OpenSSL, as an open source library widely used in secure communications, provides encryption algorithms, keys and certificate management functions. However, there are some known security vulnerabilities in its historical version, some of which are extremely harmful. This article will focus on common vulnerabilities and response measures for OpenSSL in Debian systems. DebianOpenSSL known vulnerabilities: OpenSSL has experienced several serious vulnerabilities, such as: Heart Bleeding Vulnerability (CVE-2014-0160): This vulnerability affects OpenSSL 1.0.1 to 1.0.1f and 1.0.2 to 1.0.2 beta versions. An attacker can use this vulnerability to unauthorized read sensitive information on the server, including encryption keys, etc.

The article explains how to use the pprof tool for analyzing Go performance, including enabling profiling, collecting data, and identifying common bottlenecks like CPU and memory issues.Character count: 159

The article discusses writing unit tests in Go, covering best practices, mocking techniques, and tools for efficient test management.

The library used for floating-point number operation in Go language introduces how to ensure the accuracy is...

Queue threading problem in Go crawler Colly explores the problem of using the Colly crawler library in Go language, developers often encounter problems with threads and request queues. �...

The article discusses managing Go module dependencies via go.mod, covering specification, updates, and conflict resolution. It emphasizes best practices like semantic versioning and regular updates.

Backend learning path: The exploration journey from front-end to back-end As a back-end beginner who transforms from front-end development, you already have the foundation of nodejs,...

The article discusses using table-driven tests in Go, a method that uses a table of test cases to test functions with multiple inputs and outcomes. It highlights benefits like improved readability, reduced duplication, scalability, consistency, and a
