internal errors should be wrap or encapsulated?

[lingfengChen03]

in the process of using Sometimes we needs to determine if the status of mmdb is closed or not.

errors.New("cannot call Lookup on a closed database")

Now that I'm out there judging strings, there should be a more elegant way to do it?
Looking forward to the author's recovery~

[oschwald]

Although I would accept a PR to make a more specific error type for this case, could you expand a bit on how you end up in the situation where you don't know if the reader is closed or not? In my own use, this would generally be indicative of a programming bug in the application.

[lingfengChen03]

Although I would accept a PR to make a more specific error type for this case, could you expand a bit on how you end up in the situation where you don't know if the reader is closed or not? In my own use, this would generally be indicative of a programming bug in the application.

Thank you for your reply~
In the code, there is a timer that updates the mmdb regularly, meaning that one closes the old mmdb and opens the new one, so if another read-goroutine reads it, it may return an exception, so I want to get the current mmdb status for the subsequent logic.

	go func() {
		for range ticker.C {
			if MmdbReader != nil {
				MmdbReader.Close()
			}
			// init mmdb
			MmdbReader, err = maxminddb.Open(Conf.MaxmindDb)
                         ....
		}
	}()

[oschwald]

I see. For what it is worth, in situations like this one, I atomically replace the reader and rely on the finalizer to eventually close the old one. If you don't want to rely on the finalizer, you could also start a new goroutine to close it after an appropriate amount of time has passed for your use case.