We have been frequently seeing a lot of NoDocumentExceptions from cloudant that look like this:
com.cloudant.client.org.lightcouch.NoDocumentException: 404 Object Not Found at https://xxx-bluemix.cloudant.com:443/{db name}/{doc id} Error: not_found. Reason: Database does not exist..
This happens intermittently when we try to update a document in a database that was recently created, but some cloudant nodes are unaware. We would like our code to be able differentiate between the case where the 404 indicates that database was not found (in which case we would want to retry) vs the case where the document itself is missing (in which case is may not make sense to retry the call).
The problem I have observed is that the NoDocumentException class does not have a constructor that takes the error and reason code, so calling the getError() and getReason() methods on it to drill into the details does not work, since those fields have not been set.
1. Steps to reproduce and the simplest code sample possible to demonstrate the issue
See above. The easiest way to reproduce the issue is to attempt an update to a document where the database really does not exist. In that case, you will will see that getError() and getReason() both return null.
2. What you expected to happen
The error and reason fields should be populated in the exception.
Bug Description
We have been frequently seeing a lot of NoDocumentExceptions from cloudant that look like this:
This happens intermittently when we try to update a document in a database that was recently created, but some cloudant nodes are unaware. We would like our code to be able differentiate between the case where the 404 indicates that database was not found (in which case we would want to retry) vs the case where the document itself is missing (in which case is may not make sense to retry the call).
The problem I have observed is that the
NoDocumentExceptionclass does not have a constructor that takes the error and reason code, so calling thegetError()andgetReason()methods on it to drill into the details does not work, since those fields have not been set.1. Steps to reproduce and the simplest code sample possible to demonstrate the issue
See above. The easiest way to reproduce the issue is to attempt an update to a document where the database really does not exist. In that case, you will will see that getError() and getReason() both return null.
2. What you expected to happen
The
errorandreasonfields should be populated in the exception.3. What actually happened
The
errorandreasonfields are not populated.Environment details
I saw this in both 2.17.0 and 2.19.0