lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <>
Subject [jira] Commented: (SOLR-1591) XMLWriter#writeAttr silently ignores null attribute values
Date Wed, 13 Jan 2010 15:22:54 GMT


Chris A. Mattmann commented on SOLR-1591:

shrugs - the example I gave was meant to show how defining the function to work for "null"
can simplify code that calls the function. What didn't you understand about that?

Well I understood your comment I was just confused as to how it's any better I guess. You
showed this as a simplification that having the silently ignored null allows:

writeAttr("foo", map.get("foo"));
writeAttr("foo", map.get("bar"));

Agreed, it's a bit prettier than this:

String fooVal = map.get("foo");
if (fooVal  != null) {
  writeAttr("foo", fooVal);

String barVal= map.get("bar");
if (barVal!= null) {
  writeAttr("bar", barVal);

But what about this?

if(map.get("foo")) != null writeAttr("foo", map.get("foo"));
if(map.get("bar")) != null writeAttr("bar", map.get("bar"));

No, not if the function is well defined for a null value.

It can be as well defined as you'd like but in the end it's a no-op and a waste, and more
importantly it's a silent waste, right?

And if we moved the null check to the callers, I'd argue that the null check should be entirely
left out of writeAttr - skip the extra code and let the NPE happen naturally.

+1 to this. What do you think?


> XMLWriter#writeAttr silently ignores null attribute values
> ----------------------------------------------------------
>                 Key: SOLR-1591
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: My local MacBook pro laptop.
>            Reporter: Chris A. Mattmann
>            Priority: Minor
>             Fix For: 1.5
>         Attachments: SOLR-1591.Mattmann.112209.patch.txt
> XMLWriter#writeAttr checks for val == null, and if so, does nothing. Instead of doing
nothing, it could leverage its method signature, and throw an IOException declaring that the
value provided is null. Patch, attached.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message