Bug #2481: NPE in XMLIndenter.java writing attribute with null value - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2481

closed

NPE in XMLIndenter.java writing attribute with null value

Added by David Lee about 9 years ago. Updated almost 9 years ago.

Status:

Closed

Priority:

Low

Assignee:

Michael Kay

Category:

s9api API

Sprint/Milestone:

Start date:

2015-10-22

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

Fix Committed on Branch:

Fixed in Maintenance Release:

Platforms:

Description

      saxon-version="9.6.0.7"

      saxon-edition="HE"

      java-version="1.8.0_40"

      java-name="Java HotSpot(TM) 64-Bit Server VM"

Using the saxon Serializer, StreamWriterToReciever, with INDENT option which loads tehe XMLIndenter class.

This method throws an NPE

  public void attribute(NodeName attName, SimpleType typeCode, CharSequence value, int locationId, int properties)
            throws XPathException {
        if (value.equals("preserve") &&       // --->>> if value is null here, does not need to be xml:space,  NPE
                attName.hasURI(NamespaceConstant.XML) &&
                attName.getLocalPart().equals("space") &&
                suppressedAtLevel < 0) {
            // Note, we are suppressing indentation within an xml:space="preserve" region even if a descendant
            // specifies xml:space="default
            suppressedAtLevel = level;
        }
        bufferedAttributes.addAttribute(attName, typeCode, value.toString(), locationId, properties);
        //nextReceiver.attribute(nameCode, typeCode, value, locationId, properties);
    }

Without using the INDENT option then no NPE.

Details on request

Actions

Copy link

Updated by Michael Kay about 9 years ago

Very strange one. The value parameter passed to the attribute() method on the Receiver pipeline should never be null. But I guess if the Receiver pipeline is getting its input directly from a StreamWriter, and the caller of the StreamWriter passes null as an attribute value, then it could happen. But that would be an API violation of some kind, so an NPE at some point would be appropriate.

Actions

Copy link

Updated by David Lee about 9 years ago

Michael Kay wrote:

But that would be an API violation of some kind,

Yes, I'm passing a null, hence a low priority .. however

so an NPE at some point would be appropriate.

Many other places in the saxon code nulls for values converted to ""

This exact code works perfectly if I dont set the indenting property - the null value doesnt cause an NPE.

So if "an NPE at some point would be appropriate.", ideally it should be consistant.

(I'd vote for no NPE :)

Not a blocking bug as its clearly my code should not pass a null, but it took quite a while to discover

why the NPE in this one variant of a test case and not all the others.

Actions

Copy link

Updated by Michael Kay about 9 years ago

I'm in a bit of a dilemma here, because the Javadoc for XMLStreamWriter in many cases says parameters "must not be null"; in a small number of cases (e.g. writing comments) it says "may be null", and in many other cases it says nothing. Where it does say "may be null" it fails to say what null is supposed to mean. Why comment text can be null and PI text can't is something of a mystery, and make it difficult to infer any kind of general policy. I'm going to take the stance that null is not allowed except where the spec explicitly says that it is, and will add checking on the methods of StreamWriterToReceiver to that effect. I will make this change for 9.7 but not for 9.6.

I'm very suprised that any path through the serializer should accept a null value for an attribute; the fact that there's one path that doesn't is no surprise at all.

Actions

Copy link