On Tue, Mar 24, 2009 at 4:11 PM, Caleb <caleb.epst...@gmail.com> wrote:
>
> On Mar 23, 7:16 pm, Kenton Varda <ken...@google.com> wrote:
>
>> BTW, you should always compile with -DNDEBUG unless you are building a debug
>> build.  It strips out several debug checks which makes things faster.
>
> Note that 'NDEBUG' isnt' a Google-ism, its a Standard C-ism.  It
> disables the assert() macro, removing all assertions from your code.
> This is generally good practice for production code, but just be
> careful that you're not doing anything with assert() that has side
> effects you depend on, like
>
>    assert (++i < 100);
>
> or something silly like that.  Never been bit by this myself, but I've
> seen it bite others...

Going off topic a little, but it is debatable whether assertions
should be disabled in production code. Disabling them doesn't make
incorrect code suddenly become correct. It just disguises the failure
by making the application behave in potentially *very* wonky ways
(which can include everything up to losing/destroying/corrupting
data).

On the other hand, if assertions remain enabled, you will get a clean,
clinical crash when something unexpected happens. Much easier to debug
than a tiny subtle data corruption that happened two weeks ago and
snowballed up to the point where someone noticed.

At Google, 99% of assertions remain enabled at all times. There are
some nuances (as always, mindless dogma gets you nowhere), but in
general, if it should crash during testing, it should also crash in
production. The alternative is entering the forbidden realm of
undefined/unpredictable behavior. We really much prefer to debug a
clean crash with a traceback at the error site, rather than sieving
through weirdness after the fact.

Of course, this policy is supplemented by a heavy focus on automated
testing at all granularities, a focus on designing fault tolerant
software to reduce the impact of a single server crashing, and a lot
of caution (ie. canaries) when upgrading production systems. Such a
policy can't work sanely if your release procedure is "It compiles?
Update the production servers!"

So, the question you need to ask yourself: why is it acceptable, when
something unexpected happens, to silently corrupt data and state in
production and not in testing? In most cases, I find that the answer
is "it is not. Keep the checks."

My 2¢ :-)
- 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