On Fri, 6 Jan 2017 at 12:31 David Kastrup <d...@gnu.org> wrote: Chris Yate <chrisy...@gmail.com> writes:
> On Fri, 6 Jan 2017 at 11:34 David Kastrup <d...@gnu.org> 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 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. Chris _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
