Introduction

Caused by accessing a cursor incorrectly or a error receiving a reply.

If there is an error receiving a reply, there will be a more specific error message to help diagnose the problem. As it is a bit programmatically awkward to parse an exception message, there is also an error code associated with each cause of the exception.

• cannot modify cursor after beginning iteration

  Code: 0

  You are calling a method that sets up the query after executing the query. Reset the cursor and try again.

• Get next batch send errors

  Code: 1

  Could not send the query to the database. Make sure the database is still up and the network is okay.

• cursor not found

  Code: 2

  The driver was trying to fetch more results from the database, but the database did not have a record of the query. This usually means that the cursor timed out on the server side: after a few minutes of inactivity, the database will kill a cursor (see MongoCursor::immortal() for information on preventing this).

• Couldn't get response header.

  Code: 4

• cursor->buf.pos is null

  Code: 3

  This may indicate you are out of hard driver space or some other extraordinary circumstance.

• couldn't get response header

  Code: 4

  The driver could not fetch a reply header from the database, so it gave up. Check if the database is still up and the network is connected and try the query again.

• no db response

  Code: 5

  This may not even be an error, for example, the database command "shutdown" returns no response. However, if you were expecting a response, this means the database didn't give one.

• bad response length: %d, max: %d, did the db assert?

  Code: 6

  This means that the database said that its response was greater than 4Mb or less than 0. Generally, a number greater than 5Mb should be reported to the developers as a potential database bug (max response length is 4Mb). A response of less than 0 often means a database assertion occured.

• incomplete header

  Code: 7

  Highly unusual. Occurs if the database response started out correctly, but broke off in the middle. Probably indicates a network problem.

• incomplete response

  Code: 8

  Highly unusual. Occurs if the database response started out correctly, but broke off in the middle. Probably indicates a network problem.

• couldn't find a response

  Code: 9

  If the response was cached and now cannot be located.

• error getting socket

  Code: 10

  The socket was closed or encountered an error. The driver should automatically reconnect (if possible) on the next operation.

• couldn't find reply, please try again

  Code: 11

  The driver saves any database responses it cannot immediately match with a request. This exception occurs if the driver has already passed your request's response and cannot find your response in its cache.

• error getting database response: errstr

  WSA error getting database response: errstr

  "errstr" is an io error reported directly from the C socket subsystem. On Windows, the error message is prefixed with "WSA".

• Timeout error

  Code: 13

  If there was an error while waiting for a query to complete.

• couldn't send query: <various>

  Code: 14

  C socket error on send.

Errors passed through by the database

Database errors should always trigger MongoCursorExceptions on queries. Error messages and codes are sent directly from the database and you should be able to see matching errors in the database log.

A few common database errors are listed below:

• E11000 duplicate key error index: foo.bar.$X dup key: { /* ... */ }

  Code: 11000

  Database error for duplicate keys.

• not master

  Codes: 10107, 13435, and 10058

  Not master errors, piped through by the database. Each of these will cause the driver to disconnect and attempt to find a new master. The actual error you get on failover may not be a "not master" error, depending on when the change in master occurs.

Class synopsis