[JAVA-623] Improve error code documentation Created: 16/Aug/12 Updated: 08/Dec/17 Resolved: 08/Dec/17 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Documentation |
| Affects Version/s: | 2.7.3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Oliver Gierke | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 1 |
| Labels: | documentation, error-codes | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Description |
|
Currently there's no complete documentation of the error codes wrapped into MongoExceptions. There is http://www.mongodb.org/display/DOCS/Error+Codes but that is self-entitled as highly incomplete and I've repeatedly seen users seeing other error codes popping up. See https://jira.springsource.org/browse/DATAMONGO-512 for example (-5 seems to indicate an integrity violation). |
| Comments |
| Comment by Jeffrey Yemin [ 08/Dec/17 ] | |
|
The -5 error code was a weirdness of the 2.x driver and no longer exists in the 3.x driver. | |
| Comment by Jeffrey Yemin [ 20/Aug/12 ] | |
|
Unfortunately, it could appear in other scenarios if there is a server bug or some other situation where the server does not return an error code in the response. | |
| Comment by Oliver Gierke [ 20/Aug/12 ] | |
|
That's good news. Can I assume that error codes of -5 in server versions < 2.2.0 will always represent a data integrity violation? Or might this error code also appear in other scenarios? If the former is the case I could add appropriate handling to SD MongoDb for backwards compatibility. | |
| Comment by Jeffrey Yemin [ 20/Aug/12 ] | |
|
@Oliver, never mind about the test case. I was using server version 2.2.0-rc1. Testing with server version 2.0.7 I do get -5, which means this particular case is a server bug that will be fixed in 2.2.0. | |
| Comment by Jeffrey Yemin [ 20/Aug/12 ] | |
|
@Oliver, is there a test case that demonstrates a -5 error code with the E11000 error message? In my tests I'm getting an error code of 11000. Searching through the Java code, I do see -5 used as a catch-all error code when the server does not provide one. See com.mongodb.ServerError#getCode. It's also used in com.mongodb.MongoException.CursorNotFound#CursorNotFound, but that usage is not likely relevant here. I think the most we can do here without breaking compatibility is to document -5 as the error code that is returned for a server error where no error code has been provided by the server. How does that sound? | |
| Comment by Oliver Gierke [ 20/Aug/12 ] | |
|
@Scott, Stephen - The original poster added a sample test case to https://jira.springsource.org/browse/DATAMONGO-512. Indeed, although the exception message shows E11000 as you described, the call to CommandResult.getCode() returns -5 which is not documented anywhere. As the general documentation seems to be covered in the tickets Stephen linked, shall we alter this ticket to capture the problem of an error code -5 being exposed rather than the expected E110000. It seems this is something that could be fixed on the driver level actually. | |
| Comment by Oliver Gierke [ 20/Aug/12 ] | |
|
Awesome, thanks! | |
| Comment by Stennie Steneker (Inactive) [ 16/Aug/12 ] | |
|
Hi Oliver, Thank you for the feedback. FYI, our documentation team is currently working on adding a more thorough server error code reference which will replace the limited info on the current wiki page. The related tracking issue is Cheers, | |
| Comment by Oliver Gierke [ 16/Aug/12 ] | |
|
In the linked ticket (DATAMONGO-512) the original poster claimed he got a
In general there's currently no resource documenting the error codes exposed completely. | |
| Comment by Scott Hernandez (Inactive) [ 16/Aug/12 ] | |
|
I don't see -5 anywhere here, where did it come from:
Where did that come from? The error is returned from the server (lastErrorObject) and the java code just passes it through. We can probably map it better in findAndModify, or any command for that matter, for code:11001 to an IndexViolationException (which DuplicateKey should then derive from). |