…e error in the case of query preparation until execution
This PR attempts to address item 2 mentioned in the OP of issue #144, i.e., of consistently rejecting in the public API rather than throwing.
Two notes:
Although deferring the reporting of the error may not be ideal (in the case of queries), I think this is necessary given how the chaining does not expect promises until the end, and otherwise the user will need to add try-catch blocks.
I thought it most consistent to turn close into a Promise as with the other Server methods (allowing a user to catch an error if a call to it did not first check isClosed).
…e error in the case of query preparation until execution
This PR attempts to address item 2 mentioned in the OP of issue #144, i.e., of consistently rejecting in the public API rather than throwing.
Two notes:
close
into a Promise as with the otherServer
methods (allowing a user to catch an error if a call to it did not first checkisClosed
).