Re: FACE_FROM_ID vs FACE_OPT_FROM_ID

[Paul Eggert <eggert@cs.ucla.edu>]

On 06/24/2016 03:43 PM, Eli Zaretskii wrote:
> When ENABLE_CHECKING is not defined, which is what happens by default
> in Emacs builds, we attempt to "do the best we can without crashing",
No, assertions should be always true; if an assertion fails Emacs should 
just abort, and should not try to patch around the bug. This is the 
longstanding intent of assertions, both in Emacs and in traditional 
computer science. If X is a side-effect-free expression, then after an 
eassert (X) there is no point to testing whether X is true, because X is 
already known to be true. The code 'eassert (X); if (!X) foo (X);' is 
redundant and somewhat silly, just as the code 'while (X) if (!X) foo 
(X);' is redundant and somewhat silly.

I suppose Emacs could have a different kind of check, for an expression 
that must be true when debugging but that might not be true in 
production. We could call it 'check_when_debugging (X)', say. Its 
semantics would be that Emacs aborts when debugging is enabled and X is 
false; but that X might be either true or false in production code.

However, I don't think check_when_debugging (X) would be helpful. Unlike 
eassert (X), it won't help the reader or simplify later code, because 
later code won't be able to assume that X is true. Worse, it would cause 
Emacs behavior in debugging mode to diverge further from production 
mode, and the production-only code paths would not be easily debuggable. 
The whole thing would be considerably more confusing than what Emacs 
does now.

It could be that the font and image caches are special cases that have a 
lot of bugs, and that we therefore want some sort of belt-and-suspenders 
treatment for them that goes beyond ordinary assertions. I don't see 
offhand why that would be, though. Are we getting an unusual number of 
bugs in that area, and if so what sort of bugs are they?