I'm not sure I completely understand the use case with the cross-site
scripts. Are we talking about a situation where one library initiates the
XHR and another library's event listener receives the data, where it's not
aware if the data is actually text or a binary payload? I can understand
the concerns about throwing an exception and how hard it might be to debug.
But isn't this a problem case also if we don't throw an exception and the
data is interpreted as text when it's really binary or vice versa? After
all, if you access responseText and the data is really binary, then it will
be converted to some bogus text string which could cause some pretty
insidious bugs. Please forgive me if I misunderstand, which may very well
be the case :)
Chris
On Thu, Oct 28, 2010 at 10:33 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Oct 27, 2010, at 5:36 PM, Boris Zbarsky wrote:
>
> >
> >> But both approaches would reliably throw exceptions if a client got
> things wrong.
> >
> > See, there's the thing. Neither approach is all that reliable (even to
> the point of throwing sometimes but not others for identical code), and
> access is more prone to issues where which code the exception is thrown in
> is not consistent (including being timing-dependent), if multiple listeners
> are involved.
> >
> > Do people really think that "action at a distance" situations where
> pulling slightly and innocuously on one bit of a system perturbs other parts
> of the system in fatal ways are acceptable for the web platform? They're the
> sort of things that one avoids as much as possible in other systems, but
> this thread is all about proposing such behaviors for the web platform...
>
> I don't think that kind of approach is good design. When design APIs
> (especially for a platform as widely used as the Web), it's better to design
> them with fewer possible ways to use them wrong. Making a subtle mistake
> impossible by design is better than throwing an exception when you make that
> mistake.
>
> I realize memory use is a concern and it's definitely easy to use too much
> memory in all sorts of ways. But a fragile API is an even bigger problem, in
> my opinion.
>
> Regards,
> Maciej
>
>