Oh, you're right, sorry.  Thanks for the info - it looks like this
should take care of it for me.

-dave

On Mar 23, 4:16 pm, Kenton Varda <ken...@google.com> wrote:
> Well, I think you misunderstood a few things about NDEBUG, however it's
> really not what you want to do anyway so I'm not sure why I suggested it.
>
> What you really want to do is call IsInitialized() yourself before you
> serialize, and then handle the error however you want.  You can also use
> FindInitializationErrors() to get a list of missing fields, though you
> should call IsInitialized() first since it's much faster.
>
> When you actually serialize, use the "Partial" serialization methods to make
> it skip the IsInitialized() check, e.g. SerializePartialToString().
>
> BTW, you should always compile with -DNDEBUG unless you are building a debug
> build.  It strips out several debug checks which makes things faster.
>
> On Mon, Mar 23, 2009 at 3:01 PM, Dave Bailey <d...@daveb.net> wrote:
>
> > Thanks Kenton.  Yes, I read the Google style guide a while ago and was
> > thoroughly entertained by the section on (the non-usage of) exceptions
> > at Google ;-)
>
> > Are there any performance implications of compiling generated code
> > with -DNDEBUG?  If not, I think it would be easy for me to add #define
> > NDEBUG to my generated code before the #include of the protobuf
> > headers.
>
> > Your other suggestion (generating an IsInitialized() call before the
> > serialization) may work better in that it would allow me to keep the
> > error message from getting leaked out to stderr.  I will look into
> > that as well.  Ideally, I would like the underlying code to:
>
> > 1) never abort()
> > 2) never print anything to stderr
>
> > -dave
>
> > On Mar 23, 2:50 pm, Kenton Varda <ken...@google.com> wrote:
> > > Well, note that if you compile with -DNDEBUG, the abort won't happen.  We
> > > have a no-exception policy in C++, so I don't think we can replace this
> > with
> > > an exception.  Is -DNDEBUG good enough for you or do you want to look for
> > > another solution?
>
> > > On Mon, Mar 23, 2009 at 2:32 PM, Dave Bailey <d...@daveb.net> wrote:
>
> > > > Hi,
>
> > > > libprotobuf calls abort() if one attempts to serialize a message that
> > > > is missing a required field.
>
> > > > To me, this seems excessive, because it gives the calling code no
> > > > opportunity to handle the error in a different way.
>
> > > > Here is the bug report in protobuf-perlxs:
>
> > > >http://code.google.com/p/protobuf-perlxs/issues/detail?id=5
>
> > > > I have to do a lot of gymnastics to "catch" an abort().  Is it
> > > > possible to have libprotobuf throw an exception instead, or at least
> > > > give protoc (via an option of some sort) the ability to generate code
> > > > that would cause libprotobuf throw an exception if the caller tries to
> > > > serialize a message with a missing required field?
>
> > > > This would make it possible to use the traditional Perl method of
> > > > trapping fatal errors (eval {}).
>
> > > > A similar issue will probably arise in Python if a Python binding is
> > > > developed that generates a Python wrapper around C++ code.  Python
> > > > programmers will expect a Python exception for an error like this, not
> > > > the termination of the program.
>
> > > > -dave
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to