This came up in web-platform-tests/wpt@b20e834#r85726061
Ideally API errors map uniquely to DOMExceptions, which make them actionable by the site. For example, if NoModificationAllowedError
always indicates that a file is locked and NotAllowedError
always indicates the site needs to requestPermission()
on the handle, the site can respond differently to these errors.
Currently, developers have to figure out this mapping on their own, or read the whole spec and infer this mapping. It would be nice to include a table mapping API errors to DOMExceptions that developers can use as a reference. Is there precedent for having this type of table in a spec?
That being said, it could be tricky to add a mapping that truly guarantees an error corresponds to a given API error (especially outside of the OPFS, where there's a whole host of things that could happen on the underlying OS). At the very least, here's a list of the mappings I'm aware of as a starting point...
NotAllowedError
requestPermission()
)NoModificationAllowedError
InvalidModificationError
move()
QuotaExceededError
TypeMismatchError
AbortError
move()
)InvalidStateError
Some errors are mostly relevant outside of the OPFS:
AbortError
(in addition to above)
InvalidStateError
(in addition to above)
SecurityError
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4