Re: What exception to raise?

On Sep 23, 2003, at 12:24 PM, Philippe Le Hegaret wrote:

> This has been in DOM since DOM Level 1 and we don't plan to render
> current implementations non-conformant.

It seems to me that current implementations are automatically 
non-comformant with higher DOM levels unless they change, since they 
won't have any of the new methods or interfaces. It seems to me that 
specifying the behavior of existing methods more tightly, but in a way 
that is compatible with earlier specs, is no worse. It might even make 
sense as a feature you could test for.

>> But at some point developers will want to be able to predict for any 
>> set of errors what one error they will receive. Otherwise, a 
>> try/catch in a language like Java or Javascript is going to produce 
>> varying results for the same error browser to browser. This is sure 
>> to be a sore spot for developers once DOM3 proliferates.
> The program is in fault since it's trying to do an invalid operation. 
> If
> more than one valid case applies, the program needs to be fixed imho.

Leaving things up to the implementation is in practice no favor to 
implementors. For browser-hosted implementations at least, it is often 
necessary to copy the behavior of the browser with the biggest market 
share at the time a given feature became popular. So if the spec says a 
behavior is implementation-defined, but existing apps (read: real-world 
web pages) depend on one
specific behavior, then the looseness of the spec only makes life more 
difficult for implementors.

I'm not saying this necessarily applies to exceptions. In fact, it 
almost certainly doesn't, because ECMAScript code on web pages almost 
never checks for exceptions at all. But it's important to keep this 
principle in mind when choosing what to leave as implementation-defined 

I realize, of course, that not all DOM implementations are 
browser-hosted. But this subset is very important to the web and worth 


Received on Wednesday, 24 September 2003 00:52:17 UTC