Async factory methods for Blob and File about fileapi HOT 4 OPEN

I think the difference would be that with the sync constructors you wouldn't know if construction failed; you'd only get an error as soon as something tries to read from the blob (that's already how it works today in chrome; blob construction can already fail). While with these async factories you could detect and handle these errors sooner. While I agree that most developers probably wouldn't care/bother, it does seem like some subset of developers would probably like to be able to detect these kinds of errors.

from fileapi.

I'm confused. Why would web developers ever use these async factories instead of using the existing sync ones?

from fileapi.

Are these kind of blobs you cannot read from defined properly? Does their existence mean we could bring back close() and some kind of promise-returning status getter?

from fileapi.

#154 is trying to define "blobs you can't read from" properly. Although not specifically these blobs. Some kind of status getter might make sense (especially for things like IDB, file and cache storage backed blobs that can start out readable, and later become unreadable). Not sure about close; or at least close with any guarantees on effects on quota, memory usage etc.

from fileapi.