If the documentation for a method says that the method "requires" some
condition, then it means the method may abort if the condition is not met.
 Usually these are obvious things where the method doesn't make sense if the
condition isn't true.  Passing NULL pointers in cases where they aren't
explicitly allowed can also cause crashes.
In general the library aborts when it detects programming errors -- often
only in debug mode.  Care has been taken to avoid aborting on any condition
which might be caused by invalid user input rather than by incorrect code,
since this would obviously be a security problem.

I think the aborting when serializing with missing required fields is
probably the only abort you really need to worry about, and again it's
debug-only.

You can always search the code for "CHECK", "DCHECK", "LOG(FATAL)", and
"LOG(DFATAL)" if you want a complete list.  CHECK always aborts when the
condition is false, DCHECK aborts only in debug mode (and does not compute
the condition at all in NDEBUG mode), LOG(FATAL) always aborts, and
LOG(DFATAL) aborts in debug mode but just writes a message to stderr in
NDEBUG mode.

BTW, in the next version I'm changing the default compiler flags in the unix
makefiles to include -DNDEBUG, since it seems like most people don't think
to do this themselves even when they really should.

On Tue, Apr 21, 2009 at 10:15 PM, Beit Knesset Mercazi Yad Binyamin <
eda...@gmail.com> wrote:

> Thanks for the reply - that helps.
> I guess if the NDEBUG route is recommended, we'll probably go with that.
> But just for the record - are all the cases which can cause abort()
> documented somewhere?
> Thanks,
> --edan
>
>
> On Tue, Apr 21, 2009 at 11:47 PM, Kenton Varda <ken...@google.com> wrote:
>
>> SerializeTo*() only aborts if required fields are missing.  You can
>> protect yourself against this problem in any of the following ways:
>> * Compile your release builds with NDEBUG defined.  The check will then be
>> skipped in release builds, and the message will be written even if some
>> required fields are missing.  Usually this isn't terribly harmful -- the
>> receiving end will never crash, and may even be able to handle it
>> gracefully.
>>
>> * Always call IsInitialized() yourself before serializing, to verify that
>> all required fields are set.
>>
>> * Use SerializePartialTo*(), which skip the required field check.  (But
>> compiling with NDEBUG is usually a better idea since you probably want to
>> know about this error when debugging.)
>>
>> The "invalid enum values" thing you mentioned is similar but does not
>> happen during serialization.  I think what you're referring to is the fact
>> that the set_foo() accessor for enum types aborts if the value passed in
>> does not match any of the defined values for the enum.  The only way this
>> could happen is if you explicitly casted an integer to the enum type, and
>> the integer did not match any of the enum's possible values.  This is
>> potentially illegal C++ anyway, so you should fix it.  The best way to fix
>> it is to call MyEnumType_IsValid(int_value) to verify that the integer is a
>> valid value for your enum before casting.  The enum accessor abort can also
>> be avoided in release builds by compiling with NDEBUG.
>>
>> On Tue, Apr 21, 2009 at 6:33 AM, edan <edan...@gmail.com> wrote:
>>
>>> Hi -
>>>
>>> Sometimes SerialTo* fails.  I have heard reports about missing required
>>> fields (yes, I know this is documented), but also things like invalid enum
>>> values, or the like.
>>> The problem is, it calls abort(), which means a core dump.
>>>
>>> Now I realize that this is due to a programming error, and should be
>>> caught before the software ships, but that's not always possible.
>>> Is there a way to get Serialize to raise a more catchable exception?  Or
>>> any other way so that our production code can gracefully handle these errors
>>> without termination with extreme prejudice?
>>>
>>> I couldn't find this in the docs...
>>>
>>> Thanks!
>>> --edan
>>>
>>>
>>>
>>
>
> >
>

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