Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
DOC-2021-Feb28-S4, DOC-2021-Mar14-S5, DOC-2021-Mar28-S6, DOC-2021-Apr11-S7, DOC-2021-Apr25-S8, DOC-2021-May09-S9, DOC-2021-May23-S10, DOC-2021-Jun06-S11, DOC-2021-Jun20-S12, DOC-2021-Jul04-S13, DOC-2021-Jul18-S14, DOC-2021-Aug01-S15, DOC-2021-Aug15-S16, DOC-2021-Aug29-S17, DOC-2021-Sep12-S18, DOC-2021-Sep26-S19, DOC-2021-Oct10-S20, DOC-2021-Oct24-S21, DOC-2021-Nov07-S22, DOC-2021-Nov21-S23, DOC-2021-Dec05-S24, DOC-2021-Dec19-S25, DOC-2021-Dec31-S26, DOC-2022-S1, DOC-2022-S2
Description
First, info on this page (https://docs.couchbase.com/nodejs-sdk/current/ref/error-codes.html) are not quite consistent with error messages of codes (https://docs.couchbase.com/nodejs-sdk/current/howtos/error-handling.html)
Should we expect couchbaseError cause 105 or cause
{kv!code0x02}or instanceof couchbase.DocumentExistsError (which seems behaviour of code)?
Second, "cluster was closed" and "parent cluster has been closed" errors that code can throw are not documented.
on the DocumentExistsError from Nodejs that is how the error should be propagated. I see what the user is asking, that is more of internal debugging referring to error codes but as a developer I would want to evaluate against error type or catch an exception based on error type and not number.
on the "cluster was closed" and "parent cluster has been closed" . Either its a bug that is not handled properly. Brett Lawson on the forums I see these error quite often can you please see if its due to the fact that its not handled in nodejs sdk ?