Promote more internal errors as part of the public API

[dominicbarnes]

There are quite a few non-exported error types that are returned by this API, such as parseConfigError and connectError that are not possible to be detected with errors.As or errors.Is. And unfortunately, using Unwrap() on them removes some useful context to determining the failure mode as well.

Would it be possible to include these particular errors (and probably all errors returned by this library) as part of the public API? One possibility is to just export these particular types as-is, with another option being to coalesce them into a single type.

For some context, I work on an application that accepts user input for connection settings in order to interact with their database, so I'm doing my best to handle as many errors as possible to make sure we provide descriptive and actionable error messages. The more structured context we can extract from error values, the better, and unexported types make that tricky if not impossible.

[jackc]

I'm conservative about exporting errors because they add to the public interface in a way that can be difficult to guarantee doesn't change. But I'm open to exporting more specific errors if they meet certain criteria.

My primary rule for whether an error should be part of the public interface is if anything can be done with it. i.e. if the error condition is something the calling code cannot do anything different vs. some other unknown error then I don't think it is worth exporting.

In general, I also prefer not to expose the underlying error because that becomes part of the public interface as well (at least in the sense that application code may be relying on it). However, in this case that may be the lesser evil.

Ultimately, what would make it easiest to proceed would be to know the following: when error condition X happens the application should do Y. That would help us decide how best to expose condition X.