Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

On Oct 27, 2010, at 3:14 PM, Geoffrey Garen wrote:

>>> Explicitly throwing an exception at the site that tries to access the data in the wrong way obviously and immediately points a finger at the problem.
>> 
>> Sort of.  Except the failure happens at runtime in uncontrolled circumstances and people tend to sprinkle try-and-ignore-exceptions stuff in their web code.
>> 
>>> The potential downside to an exception is not subtlety -- it's limited functionality: clients are no longer allowed to ask XHR to be more than one kind of data at once.
>> 
>> That's one problem.  The other problem is that it's easy for one client to break another without realizing it (possibly without both realizing it, depending on how testing is performed).  That's the "subtlety" issue...
> 
> 
> Agreed.
> 
> But, now clarified, your objection is about a much more minor case than originally specified: In the case of an intervening layer that not only wraps an XHR but also reads its data behind the scenes, where the intervening layer wants the data in a format that the client does not want it in, and where the client has liberally sprinkled "catch any exceptions and ignore them" code around all of the intervening layer's accesses to the XHR, and/or all its own accesses to the XHR, and the client does not know to use a debugger's "pause on exceptions" feature, the first time a client tries out this new API, it won't work, and the client won't know why.

This might not be as narrow as it seems, since the most portable way to check the amount of data read so far is to look at responseText.length, and that's a reasonable thing for an intervening library layer to do.

Regards,
Maciej

Received on Thursday, 28 October 2010 00:10:50 UTC