Nodejs SDK to support Promises

Currently error handling from the nodejs SDK is kind of a mishmash between err callback and exceptions. Where you are sure where the error will come from. Also makes the code seems a bit unnatural.
Since these days nodejs supports promises out-of-the-box (and have been for a while now). Maybe it worth considering adding support for it in the nodejs SDK.
This will allow a cleaner and modern way to work with the SDK, while remaining backward compatibility.
See other nodejs SDKs for example.

Hey @aterem,

Promises are something we’ve definitely been considering. There is some work underway with relation to updating our SDKs for future server versions which will bring some substantial changes to our APIs (and thus would be challenging to fit into the existing architectures). We hope to have something available for this soon.

In terms of the current state though, I can provide some detail on the method behind the use of callbacks and exceptions. Essentially, any programming error that occurs will be thrown as an exception, while any non-programmatic errors will be returned via the callbacks. For instance, attempting to get a document using a numeric key would throw an exception, since this is always wrong and always a programmer error. However, trying to access a document which simply does not happen exist would be returned by a callback in the future, since this is a non-programmer error.

Cheers, Brett

Interesting philosophy. I guess that the confusion starts on these gray areas. For example I got this exception.

    throw new Error('cannot perform operations on a shutdown bucket');

Error: cannot perform operations on a shutdown bucket
    at Bucket._maybeInvoke (/Users/aterem/repos/vodcontent/vodContentIngest/node_modules/couchbase/lib/bucket.js:1078:11)
    at Bucket._view (/Users/aterem/repos/vodcontent/vodContentIngest/node_modules/couchbase/lib/bucket.js:553:8)
    at Bucket.query (/Users/aterem/repos/vodcontent/vodContentIngest/node_modules/couchbase/lib/bucket.js:957:17) 

Which caused due to network issues, which prevented the bucket from re-connection.

I guess I could maintain a flag which holds the state of the bucket at all times, then check this flag before any call to SDK, but it sounds like this is what the SDK is for.

Hey @aterem,

You actually shouldn’t see that error unless the you’ve explicitly called the shutdown method, and then subsequently attempted to perform an operation on the bucket. If you’re seeing different behaviour, this is definitely a bug!

Cheers, Brett