Looking at the source for Bucket.java, the comments frequently say that null is returned in some cases (not found, for example). In that case, however, there is still a JsonDocument returned, but it’s success should be validated before further inspecting the returned document.
do you have an example of this? bucket.get("nananananahBATMAN") should return null for instance, with bucket being a Bucket (not an AsyncBucket), which is conform to the documentation.
also, which url(s) are you looking at?
Sorry, I should’ve been more complete with my original post.
That’s not the line number of the example (line 128), but that pulls in the full comment.
Basically if I call get() for a document that DNE, I get back a JsonDocument, non-null, which contains a “Not Found” status. That’s certainly a more complete return (and I like it), but the documentation indicates to code otherwise.
are you sure you are calling get from a Bucket and not an AsyncBucket? Looks like you are looking at a GetResponse and its ResponseStatus…
Even in the CouchbaseAsyncBucket this is not directly exposed (the Observable stream will be filtered, not including NOT_EXIST and so will be empty… also even if not empty the GetResponse is **map**ped to a Document).
can you share your snippet of code (with the type of all variables) along with the SDK version you’re using?
We have a wrapper around the Couchbase Client, but in essence what it does:
Cluster cluster = CouchbaseCluster.create(hosts);
Bucket bucket = cluster.openBucket("BucketName");
JsonDocument document = bucket.get("KeyDNE");
// document != null (but does have correct status information)
I’ve also noticed that replace() will replace any version of document if a CAS value of 0 is provided. Is that the correct behavior? I can understand why it might be that way (CAS of 0 == no CAS?) but it still seems like that might not be the desired behavior.
Where do you see any status information in JsonDocument? The Document interface that it follows only defines cas, expiry, id, content and recently mutationToken.
Did you implement a custom Transcoder and pass it to openBucket by any chance?
About the CAS it is indeed the desired behavior, yes. That’s why the cas is automatically populated by the SDK when getting/mutating.
Well this is embarrassing. It’s something our wrapper was doing. 
Sorry. But thanks for the answer regarding CAS 0.
It’s ok, relieved nothing is wrong with the SDK 
Care to explain what went wrong in a few words, out of curiosity? 
Basically our wrapper encapsulates the client SDK. It is set up to always return a wrapper… And the action of performing the wrapping was performed in a clever way, such that I didn’t separate the 2 different functionalities. All on me.