Re: Assertion !is_empty() failed - yet again

[Aaron Hill]

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.  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