You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem with this is that DOMException (and JS errors) are Serializable so to the caller it is ambiguous if a stored exception is successfully returned, or if the operation failed and is returning an error.
One simple approach would be to return "success and a value (an ECMAScript value or undefined), or failure and an error (a DOMException)", with specific steps saying e.g. "return success and value" or "return failure and a FooException" and then have the caller operate on "if result is failure" rather than "if result is an error". (We could make this a tuple but I think that's overkill.)
All database operations should be updated to be consistent. For example, in object store storage the phrasing of "... then this operation failed ..." should be updated to explicitly return failure.
As discussed in #430 -
In https://w3c.github.io/IndexedDB/#object-store-retrieval-operation the operation is noted to "return undefined, an ECMAScript value, or an error (a DOMException)"
The problem with this is that DOMException (and JS errors) are Serializable so to the caller it is ambiguous if a stored exception is successfully returned, or if the operation failed and is returning an error.
One simple approach would be to return "success and a value (an ECMAScript value or undefined), or failure and an error (a DOMException)", with specific steps saying e.g. "return success and value" or "return failure and a FooException" and then have the caller operate on "if result is failure" rather than "if result is an error". (We could make this a tuple but I think that's overkill.)
All database operations should be updated to be consistent. For example, in object store storage the phrasing of "... then this operation failed ..." should be updated to explicitly return failure.
@abhishek-shanthkumar or @SteveBeckerMSFT - any interest in putting up a PR for this?
The text was updated successfully, but these errors were encountered: