- From: Johnny Stenback <jst@w3c.jstenback.com>
- Date: Fri, 19 Sep 2003 11:36:55 -0700
- To: Darin Adler <darin@apple.com>
- Cc: www-dom@w3.org, intrigue@group.apple.com
I agree completely, IMO the DOM spec is broken and should not talk about throwing exceptions in impossible situations. We've run into this in Mozilla too (it just so happens that a Mozilla developer asked me about this same issue yesterday), and we can (and probably will) make our binding layer throw an exception if a negative value is passed as an unsigned type, but that exception will absolutely *not* be a DOM exception. Darin Adler wrote: > (The previous version had some confusing typos; this is a corrected > message.) > > Consider the interface CharacterData from DOM Level 1. The method > deleteData has an unsigned long parameter named count. The technical > report says that if the specified count is negative the exception > INDEX_SIZE_ERR should be raised. But since count is an unsigned long, it > makes no sense to say an exception should be raised if the count is > negative; an unsigned long can't be negative. > > In practice, this creates a problem for language binding implementors. > For example, the W3C DOM test suite has an ECMAScript test that attempts > to pass a negative number to deleteData, and expects INDEX_SIZE_ERR. But > conceptually, it's the ECMAScript DOM language binding that is going to > encounter the need to convert the negative number to an unsigned long, > and I think it may be unreasonable to expect the language binding to > know that it should raise a DOMException INDEX_SIZE_ERR in this case, > since the process of converting argument types shouldn't be required to > know details of individual DOM methods. > > I was unable to find any standard that defines what should happen to > values of inappropriate types that are passed through a language > binding. I expect that's outside the scope of the DOM technical report. > > There's definitely a problem here, but I'm not sure what can be done to > the DOM technical report to fix this. Perhaps the idea of using unsigned > long as the type in the CharacterData interface is the problem; it's > certainly inconsistent to talk about a negative count if a count is an > unsigned long. > > This issue exists for the substringData, insertData, deleteData, and > replaceData methods of the interface CharacterData, and the splitText > method of the interface Text. > > -- Darin > -- jst
Received on Friday, 19 September 2003 14:37:31 UTC