[GODRIVER-2116] Add MongoDB Error Codes as Constants Created: 05/Aug/21 Updated: 15/Dec/23 |
|
| Status: | Investigating |
| Project: | Go Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Unknown |
| Reporter: | Rushil Kumar | Assignee: | Matt Dale |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
MongoDB has a list of error codes here: https://github.com/mongodb/mongo/blob/master/src/mongo/base/error_codes.yml#L36. I think it would be helpful to have these error codes exposed as constants so that when handling `ServerErrors` when using the Go Driver, those constants can be used to handle specific errors. Otherwise, code that uses the go driver needs to copy + paste the error codes manually which can be error prone or might become out of sync. In addition, non-MongoDB employees might not easily know where to find these error codes. This came up during some work on index migration as part of Realm Sync but I think this would be beneficial to users of the Go Driver in general. |
| Comments |
| Comment by Matt Dale [ 15/Dec/23 ] |
|
Yes I did, good catch! I've updated that comment. |
| Comment by Rushil Kumar [ 12/Dec/23 ] |
|
I believe the link you included in your previous comment refers to the list of error codes in the BAAS repo, did you mean to link to something else? And yes, I agree, exposing some of the labels and error codes are consts would be helpful. Do you think this ticket would be good to capture that work? |
| Comment by Matt Dale [ 01/Dec/23 ] |
|
There is now public documentation of common error codes: https://www.mongodb.com/docs/manual/reference/error-codes/. I'm still concerned about the usability of comparing error codes in application logic because that requires deeper understanding of exactly what the error means and what related errors should be treated the same. For those reasons, we should generally discourage users from writing application logic that compares error codes directly (error codes should only be used to understand specifically what happened). Instead, we should encourage users to write application logic that compares error labels, which describes the class of error (e.g. bad input, bad database state, timeout, etc) and will result in more resilient application logic that continues to work as additional error codes are added. rushil.kumar@mongodb.com can you share more details about your specific use cases for error code constants in application logic? Could you use error labels instead of error codes for your use case? |
| Comment by Benji Rewis (Inactive) [ 11/Aug/21 ] |
|
Thanks for your improvement suggestion rushil.kumar! For context, drivers treat error labels from the server as the most reliable form of error identification and categorization. Error messages are subject to change and should therefore not be relied upon in error handling logic. Error codes are somewhere in between: they have been subject to change in the past and, while more stable than messages, are not exhaustively defined anywhere. At this point in time, we do not feel comfortable exposing error code constants as public API. Because of their apparent malleability, error code constants could introduce the potential for breaking API changes in the future. Furthermore, we’d like to encourage users to use error labels because of their relative reliability instead of error codes. Finally, the Go driver team would have to maintain these constants to make sure we do not fall out of sync with the server. From a quick poll, it seems that other drivers also do not expose error code constants for the above reasons. There is an open DOCS ticket I’ve linked to this one that describes the task of generating documentation for every error code in the server. This is not an easy task, as new error codes are always being added and even error_codes.yml only represents a subset of the codes. Once the server exposes some firm documentation on MongoDB error codes, we could reconsider adding our own constants. Let me know if you need any other help with error handling as part of your index migration project. |