Cart
[Home] [By Thread] [By Date] [Recent Entries]
Karl Waclawek wrote:
>>As for filters and handlers, they should always initialize their state
>>on startDocument(). That will prevent any errors due to reuse after
>>attempting to parse a bad document.
>>
>>
>
>I think the problem is not initialization, but rather
>"finalization) - i.e. cleanup. If a filter acquired
>resources, then it would not release them until (if ever)
>startDocument() is called again.
>
>
>
I understand, but it's possible to code around that for cases where this
is really a concern. I find it more of an issue if a chain of filters
doesn't reinitialize properly after an error termination, and
initializing state on startDocument() at least takes care of that case.
As we've discussed, the alternative being considered is to *always* call
endDocument(), even when the parse is being terminated by an exception.
This seems counter-intuitive to me, and to at least some others on this
list. If this method were called "parsingDone()" or something of the
sort I wouldn't see it as a problem; it's the actual method name and the
perceived similarity between startElement()/endElement() and
startDocument()/endDocument() that makes it feel wrong to me.
BTW, I think this is another example of how pull APIs offer a cleaner
structure than push APIs. With a pull API you link filters by passing
through calls to the next filter in the list. It's easy to use a try { }
finally { } structure to handle exception terminations in this case.
- Dennis
|
