Re: [lmi] Unit test for PDF get_extra_pages_needed() function

[Greg Chicares]

On 2018-02-12 14:52, Vadim Zeitlin wrote:
> On Mon, 12 Feb 2018 13:55:58 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> We've reached a decision. You have two choices, so please pick whichever
> GC> produces the cleanest, most maintainable code in the end:
> GC> 
> GC> (1) Do exactly what the production system does, as described above for
> GC> '--pyx=only_old_pdf'.
> GC> 
> GC> (2) If there are zero data rows, print a special PDF file containing
> GC> only a string like this:
> 
>  Just to be sure: does this mean that this PDF file should contain just a
> single page with this string? No cover page, no pages without tabular data?
> Also, no header/footer on this single page?

"Yes" to all those questions. And no signature page, either.

>  Independently of the answer to these questions, (1) above would be simpler
> to implement and so would result in most maintainable code. However I still
> think that it's not a good solution from the user point of view, so I don't
> know if I should really follow your advice and pick (1) even though I
> believe it wouldn't result in the best behaviour or do what I consider
> would be better, even if it contradicts your guideline above.

Okay, I've consulted with the panel of experts again, and the consensus
favors option two above, for the same reason you prefer it: it's
actually better from the end-user POV.

> GC> Whichever option you choose, show no diagnostic in the zero-rows case:
> GC> IOW, it's not an exceptional condition. Accordingly, do not delete the
> GC> PDF file.
> 
>  Yes, sure, this goes without saying. This question was more general, i.e.
> what should we do if the code generating the PDF still throws an exception,
> for some other reason (it won't throw it any more just because the contract
> lapsed). And I would still be interested in an answer to it, even if it's
> not urgent, of course.

It's hard to give a complete general answer at this point, and any
answer might need to be refined later, but in general I'd say that
during a census's loop-across-all-cells,
  trap-handle-break
semantics should be avoided, and
  trap-handle-resume_next
semantics are preferable. The experimental suppression of an
assertion described here:
  http://lists.nongnu.org/archive/html/lmi/2018-02/msg00078.html
happened to replace the "should be avoided" behavior with the
"preferred" behavior. Does that help? Is there a particular
concrete case that you'd like to discuss?