Comparing Exceptions and Errors

Steven Schveighoffer schveiguy at gmail.com
Mon Jun 6 15:54:16 UTC 2022


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


More information about the Digitalmars-d-learn mailing list