Thanks a lot for that reply.

I do appreciate that two messages with the same layout will parse
indifferently as each others type. In the particular situation we are
just now, A and B are completely different, so there is no possibility
of confusion there. Dealing with specific messages, we do not rely
exclusively on the correct parsing of them to identify their type.
However, we do use it to verify that specific attributes are in fact
present in one of the messages. We then have other constraints to
check that the content of the message is valid. This is where our
debate is centred. Is it reasonable to use the pb to verify at least
that initial structure even though that every wrong type of message
parsing gives an ERROR message? Does the fact that there is such a
message mean that something could go wrong or is it just information
equivalent to the false return value of the function?

Many thanks again.


On May 22, 5:44 pm, Kenton Varda <> wrote:
> You can capture log output using 
> SetLogHandler():
> <>However,
> you have a deeper problem:  Protocol Buffers does not guarantee that trying
> to parse an A from data which is actually of type B will fail.  In fact, if
> your input is a valid protocol buffer of *some* type, then the only reason
> parsing it as type A would fail is if the message did not happen to satisfy
> A's required fields.  Remember that protocol buffers are not
> self-describing, so there is no way to know for sure what a particular
> message's type is or isn't.  It may be worth reading the encoding
> documentation to understand what is actually being sent on the wire.
> In any case, what you really need to do is create a message like:
> message AorB {
>   optional A a = 1;
>   optional B b = 2;
> }
> Then send *that* message.  Now you can check has_a() and has_b() to
> distinguish the types.
> On Fri, May 22, 2009 at 3:59 AM, <> wrote:
> > Hey, there.
> > Massive discussion at work. We have two types of pb messages with
> > required fields (A & B, let's say) and we're using A.ParseFromString()
> > to determine the type. Obviously, when the message that arrives is of
> > type B, the parsing fails and we get the pertinent "Can't parse
> > message of type". Now, that comes with a capitalised ERROR at the
> > beginning of the message. Several questions now:
> > 1. Does that mean something really wrong happens inside the pb code?
> > 2. Why would this message appear inconsistently?
> > 3. Diving into the code, the output comes from line 121 of
> > (as the title of the post says ;) ). Output should redirect to the
> > GOOGLE_LOG. Is there anyway of defining where this out actually goes
> > to? Like a flag when you compile them?
> > I am aware of the ongoing discussion between required and repeated
> > fields, but the confusing bit to me as a developer is that the
> > function returns a boolean. So when I ask it to parse, should I not
> > only expect just a true and a false? Or if an error actually happens,
> > would it not be better to let me handle it? Maybe an int or error code
> > return value would be handy to indicate the exact nature of the
> > error...
> > Anyway, thanks for any thoughts on that.
> > Oh, and the response to this post is going to settle who gets to hold
> > the TV remote at the office, so this is important stuff ;)
> > Regards,
> > Dan
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to