fix(DOMParser): Align parseFromString errors with specs #454
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- throw `TypeError` on invalid mimeType argument, it is now a mandatory argument - report `fatalError` if `Document` was not created or no `documentElement` was added, to ensure we never return `undefined`. - report `fatalError` for non string source argument, instead of `error`, but only for XML - refactored MIME_TYPE to not contain functions
3f660fa to
960612b
Compare
By passing `onError` option to `DOMParser` constructor, it will be called for each kind of error that happens during parsing. The main reason for joining the different handlers, is that the current error levels make no sense, and all should currently be treated as if they are errors. If it throws the error will be wrapped into a ParseError to stop processing. If it is not provided, xmldom continues to log to the console like before. The previous `errorHandler` option has been marked deprecated. If it is a function it will be used as `onError` if present (and `onError` is not passed), but logged as a warning. If it is an object a `TypeError` will be thrown. BREAKING-CHANGE: It is no longer possible to prevent the `fatalError` from throwing by overriding it. This ensures that no further processing takes place once a fatalError occurs. Which is what the XML specifications demand. This is why so many tests needed to be changed: Now they need to handle the throwing case instead of just collecting messages.
# Conflicts: # lib/conventions.js # test/dom/element.test.js # test/dom/serializer.test.js
- drop usage of `Object.assign` since it behaves differently - all errors are reported to `console.error` - avoid log output from test - update/sync jsdoc comments
- `onErrorStopParsing` - `onWarningStopParsing` (used in typescript example) - update tons of docs - update node and typescript versions in CI workflows - npm script `test:types` requires node 14.17 due to typesript 5.1
3b1c11f to
f8c2493
Compare
and continue to sync types and docs
This was referenced Sep 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a sing
2D9A
le commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TypeErroron invalid mimeType argument, it is now a mandatory argumentfatalErrorif nodocumentElementwas added, to ensure we never return an invalid/incompletely initialized Document.fatalErrorfor non string source argument, instead oferror, but only for XMLfix: Simpler and more robust error handling
There is a new option
onErroroption that can be passed to theDOMParserconstructor:The function that is invoked for every error that occurs during parsing.
If it is not provided, all errors are reported to
console.errorand only
fatalErrors are thrown as aParseError, which prevents any further processing.If
onErrorthrows, aParserErroris thrown, which prevents any further processing.The main reason for joining the different handlers, is that the current error levels make no sense, and all should currently be treated as if they are errors.
The previous
errorHandleroption has been marked deprecated.If it is a function and
onErroris not passed it will be used asonError, but is reported as a warning.If it is an object a
TypeErrorwill be thrown as part of theDOMParserconstructor.BREAKING-CHANGE: It is no longer possible to prevent the
fatalErrorfrom throwing by settingerrorHandler. This ensures that no further processing takes place once a fatalError occurs.Which is what the XML specifications demand.
This is why so many tests needed to be changed: Now they need to handle the throwing case instead of just collecting messages.