[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:
Related
related to DOCS-335 Error Message Reference Closed
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 DOCS-335.

Cheers,
Stephen

Comment by Oliver Gierke [ 16/Aug/12 ]

In the linked ticket (DATAMONGO-512) the original poster claimed he got a

com.mongodb.CommandResult$CommandFailure and an errorcode "-5".

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:

org.springframework.data.mongodb.UncategorizedMongoDbException: command failed [command failed [findandmodify] { "serverUsed" : "localhost:27017" , "lastErrorObject" : { "err" : "E11000 duplicate key error index: oneview.user.$foreignAccounts.TWITTER.foreignId_1 dup key: { : \"100003485885211\" }" , "code" : 11001 , "n" : 0 , "connectionId" : 205 , "ok" : 1.0} ,...

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).

Generated at Thu Feb 08 08:52:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.