You MUST validate user input and user input validation failures are a class of errors not exceptions.
For example look at java (which uses the opposite terminology but exact same concept). Checked exceptions are expected state that should be handled gracefully, unchecked exceptions and errors are unexpected and the handling of them is generally let someone know what happened and exit quickly.
This is bizarre: it sounds like you're disagreeing with me, by agreeing with me (that this is an error, not an exception)! For the confused (myself included), please realize that lost953's argument is considered "begging the question" (a logical fallacy [1]): You're using your a-priori assumption that 'divide by zero' is an exception, to argue that what we really should be doing here is add an if-guard before the "actual divide" occurs, so we can return an error, instead of an exception!
Otherwise, thank you for conceding that exceptions are just a category of error :)
> No you misread my refutation, I make no claims of the errorness or exceptionness of dividing by 0,
Hmmm.
calc_div(num: Number, den: Number) -> (Error | Number):
if den == 0:
return Error("division by zero")
else
return num / den
If you take the latter approach, then the caller has to have a way of accepting the error gracefully, as a normal thing that might happen. And thus we have a div0 that is an error rather than an exception.
den is a tiny non-zero value in an 80-bit register. It gets spilled to a 64-bit slot on the stack, rounding it to zero, while another copy of it remains in an 80-bit register. The 80-bit version is compared against zero, and is non-zero. The 64-bit version, which is zero, gets used for the division.
It is fully standards-compliant for a C compiler to do this. Some languages may specify otherwise, but often the behavior is unspecified or is implicitly the same as C.
However if you do use floating point, then the kind of dangers you point out make my point even stronger. You could conceivably embed the `calc_div` function in a larger system that knew about pre-validating for div0. But if you want to deal with all possible sources of FP weirdness when doing division, then you really need to concentrate it in the "division expert": i.e. have calc_div pre validate all that stuff, and have its caller accept that errors are a normal result.
One guideline I follow for choosing between error codes and exceptions is “can the immediate caller do anything about this issue?” Even if the calculator does feed user input directly into the math library, the calculator can’t do anything sensible with an invalid statement. The calculator will have to “go up a level” and ask the user for help.