[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: Chris Yate
Subject: Re: [2.20] Issue 4943 Manual page breaking causing assertion failure using Windows
Date: Fri, 06 Jan 2017 12:52:42 +0000

On Fri, 6 Jan 2017 at 12:31 David Kastrup <address@hidden> wrote:

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
> 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

All very well for avoiding a crash, but of course that doesn't solve the
problem, if whatever bug or issue it is that's causing the problem is
affecting the page breaking of scores.

IIRC that code goes back a long way, and the knowledge of why it's
asserting at all may have been lost.


reply via email to

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