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 -~----------~----~----~----~------~----~------~--~---
