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. 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.
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.
From my perspective, it seems all of the reported situations that are
actually failing the assertion involve edge cases where allowing the
function to return a value just so execution can proceed would resolve
the "issue" end users are having. And by "issue", I only mean the
unexpected and undesired program termination.
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.
-- Aaron
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
