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.