jOOQ/jOOX

Match.content() returns "" instead of null

Closed this issue · 6 comments

As the document said,

    /**
     * Get the XML content of the first element in the set of matched elements,
     * or <code>null</code> if there are no matched elements
     * <p>
     * This is the same as calling <code>content(0)</code>
     */
    String content();

Match.content() should return null if no matched elements found, but now it returns "" (empty string) here.

private final String content(Element element) {
    if (element == null) {
        return "";
    }
    ....

Thank you very much for your report. Intuitively, I'd say the documentation is wrong as this method should be safely expected to never return null. Will investigate soon.

I suggest return null instead of "", since the content() result is not to be chainable, and with null is easy to check whether the element exists or not.

Why abuse Match.content() for existence checks (a very expensive operation in case of existence!) when there is Match.isEmpty()?

Because I need the content.

$(parent).children().forEach($child -> {
    String content = $child.child("name").content();
    if (content == null)
        ....
    else
        ....
});

otherwise

$(parent).children().forEach($child -> {
    Match $childName = $child.child("name");
    if ($childName.isEmpty())
        ....
    else {
        String content = $childName.content();
        ....
    }
});

I need to store $childName as a variable.
Am I right? Or any better approach?

OK, I see. I'll have to think about this.

I checked, the Match.text() method does return null as specified by the Javadoc, so there's certainly an inconsistency here. Making this consistent will break backwards compatibility in any case, so perhaps we could really return null from content().

Likewise, I just checked what jQuery.html() does, when jQuery doesn't match anything (e.g. jQuery(".non-matching-selector").html(). It also returns a JavaScript null value.

OK, I've given this more thought and I agree with you:

  1. The existing Javadoc is right and the behaviour will be adapted
  2. This is consistent with Match.text() (Javadoc and behaviour)
  3. This is consistent with jQuery