Comment #40 on issue 57 by ken...@google.com: null values should be treated
as no value
OK, look: The vast majority of the people I talk to about this agree that
current behavior is correct. Of course, these people, being happy with the
quo, don't usually come out to argue about it, which is why you see mostly
on this thread.
Now, I'd of course like to find a solution that pleases everybody.
However, I note
- After a successful call to setFoo(x), getFoo() should return x. I refuse
implement anything in which this is not the case.
- If getFoo() returns x before serialization, then after serializing and
the message, it must still return x. I refuse to implement anything in
which this is
not the case.
- There is no "null" in the protocol buffers encoding. We cannot add one
as not only
would it break compatibility, but it simply would not work in some other
In C++, for example, the getters return references, which cannot be null.
languages have no concept of null at all.
- A major reason why there is no "null" is because it would tend to lead to
problems. If getFoo() could return null, and some caller failed to check
then it would be trivial for an attacker to exploit that by sending a null
But, such problems could easily pass normal testing if the test clients
to send null values, which could easily be the case for many apps. This
especially problematic for C++ servers.
- Having getFoo() return null when hasFoo() is false would obviously lead
to the same
problems. Additionally, it would break lots of existing code, and would
many people who like the fact that they can write
"getFoo().getBar().getBaz().hasQux()" without having to check hasFoo(),
Therefore we simply cannot have setFoo(null) do anything except throw NPE.
Now, what can we do instead? I am open to the idea of introducing a
accessor which has the behavior you want. Some open questions about this:
- How much will this increase generated code size? Note that code size is
problem for protocol buffers at present. The overhead would have to be no
a percent or two.
- Should primitive fields also get a setOrClearFoo() accessor, taking the
as the input?
So far no one has sent me a patch implementing this or examining the code
Sorry, I don't have time to write it myself.
Note that as of version 2.3.0, you could actually implement setOrClearFoo()
code generator plugin which inserts code into the classes generated by
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
You received this message because you are subscribed to the Google Groups "Protocol
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at