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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
