3 Comments »

1. Does it mean that all old NS_ASSERTIONs should be renamed to NS_ABORT_IF_FALSE?

   Anywhere on the web that mentions the differences between the two?

   -not-technically-inclined-in-this-area-

   [There’s a semantic difference between the two, naturally, that makes the obvious rename not applicable. NS_ASSERTION will print an error message when the condition is false in a debug build, but execution will continue. NS_ABORT_IF_FALSE will print the error message and then abort. We have many instances of the former that do get hit and can’t blindly be converted, not without other pieces of code also being fixed. That’s why I only specified this for new assertions; if it’s new, we don’t have those legacy-so-wasn’t-fatal-before situations.

   I added NS_ABORT_IF_FALSE to MDC and modified NS_ASSERTION to mention NS_ABORT_IF_FALSE as the preferred alternative. If you see other documentation on this, feel free to update it.]

   Comment by Gary Kwong — 04.01.09 @ 22:34

2. NS_ASSERTION is often used when NS_WARNING should be used.
   We should try to clean up the mess and change
   NS_ASSERTION to be really an assertion, not just a warning.

   [I hear people saying this, but I’ve never seen cases where it’s actually happened that an assert was used instead of a warning. Maybe I’m just not looking at the right code…]

   Comment by smaug — 05.01.09 @ 02:14

3. I assume your reasoning is because NS_ASSERTION is weirdly named in that it behaves differently from assert(2)? Or is there more to it than that?

   [You can ignore NS_ASSERTION because it complains to the console and otherwise does nothing else (and because, apparently, Windows hackers force that behavior instead of dealing with incessant dialogs). You can’t ignore NS_ABORT_IF_FALSE because it’s an application crash; I guess that’s the same thing assert(2) does, so that’s basically it.]

   Comment by Dan Mosedale — 05.01.09 @ 14:52

RSS feed for comments on this post. TrackBack URI

Leave a comment