@Isabella_Siu -
This is coming along nicely - thank you so much for sharing the proposal with us.
I love the idea of extending the error types to have .HasErrorCode() and .HasErrorLabel(), but I personally am with @Alessandro_Sanino in that I’d also like iota enumerated types so that performing error checking is really light and fast.
Taking a look at the new IsDup error function, I can see that while this proposal simplifies some logic, at the end of the day, it doesn’t seem to solve the fundamental issue. This line in particular is what’s concerning me (e.HasErrorCode(16460) && strings.Contains(e.Error(), " E11000 ")). If there is one error code in the error type and another code in the string, then it doesn’t seem like it’s simple to determine what the actual error is.
Maybe something that might help is to create an internal map in mongo-go-driver. Extrapolate certain error codes to categories. So rather than having an IsDup function, the error could contain an additional field/accessor, ErrorCategory(), in this case it would be set to an iota int const of DuplicateKey, which is set by the driver when the result comes back from the database (as opposed to having to call it after every insert). I would argue that there are quite a few errors that could be categorized.
Having fine-grained access to the specific code/error is nice, but since there’s no documentation on what the individual error codes mean outside of the golang driver (e.g. DuckDuckGo & Google). Having the low level error code just typically isn’t directly helpful.
Possible map
type ErrorCategory int {
ErrDuplicateKey iota
ErrDuplicateIndex
}
errCategoryMap := map[int]int{
11000: ErrDuplicateKey,
11001: ErrDuplicateKey,
...
}