[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