547f119be6
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). |
||
|---|---|---|
| .. | ||
| chromium | ||
| features | ||
| font | ||
| pdfs | ||
| resources | ||
| stats | ||
| ttx | ||
| unit | ||
| .eslintrc | ||
| .gitignore | ||
| annotation_layer_builder_overrides.css | ||
| downloadutils.js | ||
| driver.js | ||
| test_manifest.json | ||
| test_slave.html | ||
| test.js | ||
| testutils.js | ||
| text_layer_test.css | ||
| webbrowser.js | ||
| webserver.js | ||