Simplify the error handling slightly in the src/display/node_stream.js file

The various classes have `this._errored` and `this._reason` properties, where the first one is a boolean indicating if an error was encountered and the second one contains the actual `Error` (or `null` initially).

In practice this means that errors are basically tracked *twice*, rather than just once. This kind of double-bookkeeping is generally a bad idea, since it's quite easy for the properties to (accidentally) get into an inconsistent state whenever the relevant code is modified.

Rather than using a separate boolean, we can just as well check the "error" property directly (since `null` is falsy).

---

Somewhat unrelated to this patch, but `src/display/node_stream.js` is currently *not* handling errors in a consistent or even correct way; compared with `src/display/network.js` and `src/display/fetch_stream.js`.
Obviously using the `createResponseStatusError` utility function, from `src/display/network_utils.js`, might not make much sense in a Node.js environment. However at the *very* least it seems that `MissingPDFException`, or `UnknownErrorException` when one cannot tell that the PDF file is "missing", should be manually thrown.

As is, the API (i.e. `getDocument`) is not returning the *expected* errors when loading fails in Node.js environments (as evident from the `pending` API unit-test).
This commit is contained in:
Jonas Jenwald 2018-06-05 20:30:26 +02:00
parent 2fdaa3d54c
commit 547f119be6
2 changed files with 18 additions and 23 deletions

View file

@ -164,7 +164,9 @@ describe('api', function() {
});
it('creates pdf doc from non-existent URL', function(done) {
if (isNodeJS()) {
pending('XMLHttpRequest is not supported in Node.js.');
pending('Fix `src/display/node_stream.js` to actually throw ' +
'a `MissingPDFException` in all cases where a PDF file ' +
'cannot be found, such that this test-case can be enabled.');
}
var loadingTask = getDocument(
buildGetDocumentParams('non-existent.pdf'));