- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 28 Oct 2010 10:33:18 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Geoffrey Garen <ggaren@apple.com>, Darin Fisher <darin@chromium.org>, Chris Rogers <crogers@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Alexey Proskuryakov <ap@webkit.org>, Chris Marrin <cmarrin@apple.com>, jorlow@google.com, jamesr@chromium.org
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
Received on Thursday, 28 October 2010 17:33:54 UTC