Owner: ken...@google.com

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 the current behavior is correct. Of course, these people, being happy with the status quo, don't usually come out to argue about it, which is why you see mostly complaints
on this thread.

Now, I'd of course like to find a solution that pleases everybody. However, I note
the following:
- After a successful call to setFoo(x), getFoo() should return x. I refuse to
implement anything in which this is not the case.
- If getFoo() returns x before serialization, then after serializing and re-parsing 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 languages. In C++, for example, the getters return references, which cannot be null. Some
languages have no concept of null at all.
- A major reason why there is no "null" is because it would tend to lead to security problems. If getFoo() could return null, and some caller failed to check for that, then it would be trivial for an attacker to exploit that by sending a null value. But, such problems could easily pass normal testing if the test clients never happen to send null values, which could easily be the case for many apps. This would be
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 disappoint
many people who like the fact that they can write
"getFoo().getBar().getBaz().hasQux()" without having to check hasFoo(), hasBar(), or
hasBaz() explicitly.

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 setOrClearFoo()
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 a huge problem for protocol buffers at present. The overhead would have to be no more than
a percent or two.
- Should primitive fields also get a setOrClearFoo() accessor, taking the boxed type
as the input?

So far no one has sent me a patch implementing this or examining the code size issue.
Sorry, I don't have time to write it myself.

Note that as of version 2.3.0, you could actually implement setOrClearFoo() via a code generator plugin which inserts code into the classes generated by protoc. See:


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 
Buffers" group.
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 

Reply via email to