Re: [Libreoffice] Assertions and Logging

On 11/21/2011 01:30 PM, Caolán McNamara wrote:
> On Fri, 2011-11-18 at 15:25 +0100, Stephan Bergmann wrote:
>
> Alright, so we end up with
> use assert if you want an assert
> SAL_WARN if you want to warn about something odd, but which isn't
> necessarily definitely wrong
> SAL_INFO for verbose logging
>
> Practical question though, is on windows where does the output go ?

SAL_INFO/WARN just go to stderr for now.  What should work to see them 
even for a gui soffice.exe is to add something like 2>log.txt to the 
command line.  Not sure if there is enough of a Windows developer base 
that demands a more sophisticated solution?  (One could extend the 
SAL_LOG environment variable, so that a trailing ">file" part would 
append the data to a given file, for example.  Or see to hook up Window' 
OutputDebugString.)

> Should we write off all the DBG_ASSERTs as hopeless to unwind and mass
> convert them all to SAL_WARNs ?

I would initially file an easy hack to do the conversion.  If that does 
not lead to clean-up in a reasonable time-frame, I would suggest to 
mass-convert the remainder to SAL_WARN.

> How do we feel about code that does e.g.
>
> assert(pFoo);
> if (!pFoo)
>      throw catchAbleFoo("wtf");
>
> i.e. do we have a philosophical problem with gracefully/semi-gracefully
> handing should-be impossible cases ?

I think that's a perversion, and should be avoided.  It the author could 
not convince himself that !pFoo is not impossible (modulo bugs), then he 
should use OSL_WARN instead.  If however he *is* convinced that !pFoo is 
impossible absent any bugs, but argues that if there *are* bugs, the 
added if statement adds some sort of safety, I would counter-argue that 
this alleged safety net pointlessly increases complexity and is probably 
full of holes and inconsistencies anyway (as it is likely an extremely 
untested code path).

Such defensive programming IMO would need to be architected into the 
code from the beginning.  It makes little sense to add such things 
locally just here and there.  And I'm not even convinced LO is an 
application for which an elaborate defensive programming architecture 
would be justified.  If there is a bug, crash early.  (One thing we 
could IMO improve though, is to not rely on trying to save open 
documents from within a signal handler, but instead rely on frequent 
auto-save and roll back to the last saved version after a crash.)

Stephan