[Top][All Lists]

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

Re: Assertion !is_empty() failed - yet again

From: Aaron Hill
Subject: Re: Assertion !is_empty() failed - yet again
Date: Sat, 02 Nov 2019 04:30:17 -0700
User-agent: Roundcube Webmail/1.3.8

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

reply via email to

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