Aaron Hill <aa...@hillvisions.com> writes: > On 2019-11-01 1:19 pm, David Kastrup wrote: >> Aaron Hill <lilyp...@hillvisions.com> writes: >>> That said, I feel the hard-fail approach of an assertion is too >>> strong, and what we need is to simply emit a warning that the function >>> will be returning the midpoint of the interval's bounds despite the >>> interval appearing to be invalid (read: empty). >> >> There are lots of situations where this assertion may trigger and not >> all of them may have a sensible fallback. So one would need to see >> what >> particular case is triggered here. > > I understand the assertion may be guarding against unexpected > behavior. This is why I would not propose removing the assertion > without putting something back in place such as a warning.
An assertion is used if the program cannot be guaranteed to continue without crashing or internal corruption. A warning is not the same. > And to reiterate what I said in my earlier follow-up, my proposal > would not be unprecedented given the existing "crossing fingers" > messages that can appear from time-to-time. "Crossing fingers" messages are appropriate when there is a useful fallback behavior. > Given that, what makes this particular function so special as to hold > it to a higher standard? It is not like computing the center of an > inverted interval is perilous in and of itself. The caller might not > like the result, but that is their fault for asking a silly question > in the first place. The caller may rely on well-defined behavior. > Yes, there is an underlying computational error that is producing > inverted intervals. Yes, the end result of continued execution may > not produce what the user expects or needs. But, hard failing the > process is only a thorn that punishes the end user. At the very > least, this should be a *debug* assertion--not a run-time error. A caller should not call this function if its input can be an empty interval. This is clearly a programming error without a sensible default fallback behavior: any fallbacks need to be implemented by the caller. -- David Kastrup _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond