>> 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. >> I don't think it's possible to answer that question until someone fleshes >> out your assumption that libraries routinely intercept XHRs in transit and >> read their data. Which libraries do this, when, and why? > > jquery, offhand, layers API on top of XHR. Right, but that's not the same as reading the XHR's data as it arrives. > Again, at this point I'd welcome comments from library authors. Agreed. > I think we're sort of at an impasse pending that in that clearly I'm not > able to convince you and I don't think repeating the same thing over and over > will convince me either. I don't think I've repeated the same thing -- I think I've clarified the limited and unproven nature of the circumstances in which an exception-based API might not work. >>> This make it impossible to decide whether to look at the text or the bytes >>> based on the content-type of the response (unless you allow setting the >>> attribute in some early-enough onStateChange callback _and_ libraries >>> expose XHRs in that early a state to consumers); having that ability seems >>> like a desirable feature. >> >> I'm not convinced that clients loading resources from their own domains >> somehow won't know the types of those resources. > > Why are you making the "from their own domains" assumption? Because that's by far the most common use of XHR. >> But, if we believe this is a real concern, it seems fine to me to allow >> responseType to be set some time after open, or even set implicitly by the >> first access to a certain view of the response. > > If we do go with the modal behavior, I would be _very_ opposed to the "first > view" approach. That just makes the problems that worry me that much worse, > since now it's _really_ easy for one consumer to screw over another without > really realizing it's doing so, and debugging such a failure is very > difficult. At least with the explicit flagging one can look for where such > flagging took place.... The only difference between the first view approach and requiring explicit assignment to .responseText is which syntactic construct you would search for when something went wrong -- access or assignment. But both approaches would reliably throw exceptions if a client got things wrong. Anyway, I'm fine with making this behavior explicit, too. Geoff
