Re: [whatwg/storage] Error handling in estimate() (#38)

Two of the legacy quota APIs in Chrome do support an error callback; tracing through the code the most common uses are in cases that would be out of scope with the new API, e.g. calling from a file: origin or origins not allowed to store data. But we do route failures in the quota system out in a few places, e.g. InvalidAccessError (e.g. if the quota DB can't be initialized) or AbortError (e.g. to pending queries if the back end is shutting down). These aren't tested from script (i.e. we don't plumb through a "nerf the quota back end" testing API). 

I would expect this could happen in other implementations (although some may choose to terminate in the face of such failure - always an option). I'd be in favor of an escape hatch in the spec that if the site storage usage or quota cannot be determined, reject with UnknownError so that implementations do converge on a behavior. For example, I think my estimate() impl in Chrome probably plumbs through the same errors as the legacy APIs since it's really just a promise shim (in C++) over the legacy callback impl; I should probably map those to generic UnknownError.


 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/storage/issues/38#issuecomment-263948440