Re: The "splice" call

>>It seems that an exception would be called for (and I am beginning to
>>think most of these exceptions should be "run time" exceptions when they
>>represent a programming error because programmers would rarely have
>>alternate behavior for programming errors).
>
>That sounds reasonable ...

Uh-oh. Another religious point. Runtime errors should be those that truly
CAN'T be dealt with--out of memory errors, illegal instructions, etc.
Things that basically mean the system is all screwed up, and there is
nothing the programmer could do to recover, so there is no need to catch the
exception.

Programming errors should be caught with explicit exceptions, and
programmers should be forced to deal with those errors--that's one of the
principles behind the "design by contract" ideas behind specifying the
exceptions thrown by a method.  The interface is a contract between the
implementor and the client--and exceptions are consequences of clients not
upholding their side of the agreement.

Speaking of which.... It may actually be a good idea to specify a
"ValidationException" that may be thrown by Node.insertBefore and
AttributeList.setAttribute, (and maybe for other methods that modify the
DOM) if only as a placeholder for the Level 2 (or 3 or 4) work.  I think
this was mentioned before, but I think it was "deferred".  Without the
exception defined, an implementor wanting to perform immediate validation
(e.g. for documents constructed outside of a parser) MUST resort to runtime
exceptions. If the ValidationException is defined, implementations can (but
are not required to) perform immediate validation.

>>Splice is just as
>>useful for elements with children as for text with characters.  For that
>>matter, iterators are at least as useful for text with characters as in
>>their current form for elements with children.

I'd advise caution here. Advanced operations can be provided by
implementations that add value to the standard specification. And I think
splice is one of those operations. While it is certainly necessary for a
certain class of applications, others won't require it at all. I'd prefer
that it be removed from the interface. The more complicated the interfaces,
the more difficult they are to implement (take the recent discussion on
NodeIterators as proof of this argument), and the greater the chances for
differences in implementation to have an adverse affect on interoperability.

Jeff Mackay
Vtopia, Inc.

Received on Wednesday, 20 May 1998 00:51:17 UTC