lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] PATCH: use std::uncaught_exceptions()


From: Greg Chicares
Subject: Re: [lmi] PATCH: use std::uncaught_exceptions()
Date: Sun, 25 Mar 2018 16:10:24 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2018-03-24 22:34, Vadim Zeitlin wrote:
> On Sat, 24 Mar 2018 21:19:34 +0000 Greg Chicares <address@hidden> wrote:

[...lmi must never produce an invalid illustration--i.e., PDF file...]

> GC>  - throw in the dtor when not unwinding, even though that goes
> GC>    against accepted pre-C++17 wisdom?
> 
>  I guess we should indeed use LMI_ASSERT() and throw from the dtor. It also
> seems that we need to delete the PDF output file, if it exists, if an
> exception was thrown.

Let's establish the premises first.

(1) AIUI, PDF files are generated something like this:
  (a) create PDF file for output
  (b) append stuff: b1, b2, b3...
  (c) close the file
and it's my impression that any error in (b) leaves a file that may
be syntactically valid. For example, I've seen the wxPdfDoc code
create PDF files that can be opened in a PDF viewer but appear to
have no contents. I think this is why you say above:
| seems that we need to delete the PDF output file, if it exists, if an
| exception was thrown.
but correct me if I'm wrong.

(2) For a long time, "never let exceptions escape from destructors"
has been the usual advice, and our production system has always
followed that "best practice". C++17 adds std::uncaught_exceptions(),
which lets us throw from dtors safely under certain circumstances.
Someday I'll probably learn enough about this to become comfortable
with it, but that will take time and effort. Maybe now is the time,
or maybe not; but until I invest that effort, accepting this new
idiom into production is an avoidable risk, and I am risk averse.

Now we have a situation that calls for rollback semantics, which
can now (2) theoretically be implemented in dtors. But I think we're
also saying that these particular rollback semantics require an
extra step (1), so we can't solve the problem in the dtor. If that
analysis is correct, then we need a separate postcondition-checking
step that deletes the file if they haven't been established; and in
that case the dtor might just as well set a failure flag instead of
throwing.

> I'm not sure if this should be done in
> write_ledger_as_pdf() itself or if it might make sense to do this in
> ledger_emitter::emit_cell(), for all file types instead?

It is for PDF illustrations that postconditions matter most of all,
because that's our most stringently regulated output. Errors in
some other types of output might be less grave (e.g., output files
captioned "not to be shared with the public" are outside the scope
of consumer-protection laws); or they might be perfectly okay, as
in the 'mce_emit_test_data' case, where the output files aren't
even comprehensible to non-specialists.

Therefore, it seems that write_ledger_as_pdf() is the right place
to handle PDF-generation errors.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]