[Top][All Lists]

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

Re: [2.20] Issue 4943 Manual page breaking causing assertion failure usi

From: David Kastrup
Subject: Re: [2.20] Issue 4943 Manual page breaking causing assertion failure using Windows
Date: Fri, 06 Jan 2017 13:31:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Chris Yate <address@hidden> writes:

> On Fri, 6 Jan 2017 at 11:34 David Kastrup <address@hidden> wrote:
>> Assertions should not be used when LilyPond has a sane way to continue:
>> for that case, programming errors are more appropriate.  The question is
>> whether this is the case here: I think we are also dealing with bad
>> output even when assertions are disabled: right?
>> But as long as it is not _dangerous_ to continue (like using 0 pointers
>> or uninitialized data), a programming error might be more suitable.
>> --
>> David Kastrup
> David,
> In this case it's hard to tell whether the output is bad, because I can't
> get past the program termination. Though I would in general agree; and
> moreover I wouldn't expect a 'Release' build to have assertions enabled.
> But this is alerting us to something that **Should not happen** at runtime,
> and ignoring that smells worse to me than having the assertion.

It would make sense to provide a macro ly_assert which basically does
the formatting of assert but produces a programming error and continues.
Obviously, it should only be used where continuing is a feasible option.

But it would make the "turn assertions of non-fatal conditions into
programming errors" task require a lot less effort and decision-making.

David Kastrup

reply via email to

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