bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Assertion !is_empty() failed - yet again


From: David Kastrup
Subject: Re: Assertion !is_empty() failed - yet again
Date: Mon, 04 Nov 2019 01:11:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Aaron Hill <address@hidden> writes:

> On 2019-11-01 1:19 pm, David Kastrup wrote:
>> Aaron Hill <address@hidden> 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



reply via email to

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