Creating an ArrayBuffer can fail about xhr HOT 9 CLOSED

Thanks, Blink's behavior now follows suit.

from xhr.

So return null and then keep returning null thereafter? As in, once you fail to get the data, you're never going to get it, even if you free up some memory?

It does have the benefit of consistency....

from xhr.

Oh, and I guess the spec actually defines the lazy allocation behavior inside the response getter that Gecko has, so at least that part will be consistent...

from xhr.

Yeah, once you fail to get the data you won't get it unless you fetch it again and get lucky.

from xhr.

That's what happens for fetch() too since it effectively tries to consume the stream and then create the ArrayBuffer with the result. If you cannot create the ArrayBuffer, you cannot really unconsume the stream either (not that that even makes sense).

from xhr.

Currently, Chrome crashes when it fails to allocate an ArrayBuffer as it wasn't specified to throw an exception in the spec at the time we decided how to handle the case.

Unless there'll be any confusion, returning null should be fine. What's the reliable way to distinguish alloc failure and other errors (network error)? Saw "load" being dispatched, but seeing null on response?

+1 to Boris regarding consistency.

from xhr.

@tyoshino, yeah, I guess that would be the way they get distinguished indeed.

from xhr.

If allocation of the underlying buffer fails, https://xhr.spec.whatwg.org/#arraybuffer-response tells us to return a null response object, along with resetting 'received bytes' to empty. Doesn't that imply that the next property access of response will return an empty array buffer, and not null - is that intentional?

(This came up via https://codereview.chromium.org/2730943002/ )

from xhr.

Yeah that is broken. Proposal: response object can be an object, failure, or null and we update all the places that use it accordingly. I don't think we can get away with not using some extra state somehow.

from xhr.