On 6/6/22 12:59 AM, Ola Fosheim Grøstad wrote:
On Sunday, 5 June 2022 at 23:57:19 UTC, Steven Schveighoffer wrote:
It basically says "If this condition is false, this entire program is
invalid, and I don't know how to continue from here."
No, it says: this function failed to uphold this invariant. You can
perfectly well recover if you know what that function touches.
For instance if a sort function fails, then you can call a slower sort
function.
If it's an expected part of the sorting algorithm that it *may fail to
sort*, then that's not an Error, that's an Exception.
Or in terms of actors/tasks: if one actor-solver fails numerically, then
you can recover and use a different actor-solver.
If the condition is recoverable => Exception. If it is not recoverable
=> Error.
An assert says nothing about the whole program.
An assert says that something is wrong, and this was not expected or
foreseen. It says that the programmer cannot attribute exactly where
this went wrong because otherwise, he would have accounted for it, or
thrown an Exception instead (or some other mitigation). Anything from
memory corruption, to faulty hardware, to bugs in the code, could be the
cause.
An assert only says that the logic of that particular function is not
meeting the SPEC.
That's one possible reason. But if you are *planning* on possibly not
meeting the spec (such as your sort example), that is a different story.
Only the programmer knows if recovery is possible, not the compiler.
Exactly. Use Exceptions if it's recoverable, Errors if it's not.
A failed assert is not implying undefined behaviour in @safe code.
A failed assert could be because of undefined behavior. It doesn't
*imply* it, but it cannot be ruled out.
-Steve
