[lost953]

I disagree with your case, this is clearly an error because it should never get to dividing by 0.

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.

[electrograv]

> I disagree with your case, this is clearly an error because it should never get to dividing by 0. You MUST validate user input and user input validation failures are a class of errors not exceptions.

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 :)

[1] https://en.wikipedia.org/wiki/Begging_the_question

[lost953]

No you misread my refutation, I make no claims of the errorness or exceptionness of dividing by 0, merely that your proposed example doesn't support your claim that it depends on the nature of the application. I claim that unchecked user input falls into the category of 'error' and that clearly is what has occurred in your proposed example.

[fao_]

> I disagree with your case, this is clearly an error because it should never get to dividing by 0.

> No you misread my refutation, I make no claims of the errorness or exceptionness of dividing by 0,

Hmmm.

[sethrin]

I understand them to be saying that if execution is supposed to be halted before the division occurs, then whether the division is an exception or an error is a moot point.

[adrianratnapala]

I think the point the GP is making is that your calculator might have a function like like

   calc_div(num: Number, den: Number) -> (Error | Number):
     if den ==  0:
        return Error("division by zero")
     else
        return num / den

Now this function pre-validates the data. But it might be used as part of a much larger system. Should that system be programmed to know that `den` should always be non-zero and pre-pre-validate accordingly? Or else should it leave "calc_div" to be the expert on the rules for division?

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.

[burfog]

Ah, but floating-point math is such fun! Here is how it might work...

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.

[adrianratnapala]

For many use cases, it a bad idea for a calculator program to use floating point, rather some more exact representation.

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.

[maxlybbert]

“Divide by zero” is an exception in the math library. But a GUI calculator shouldn’t pass all input to the math library without parsing it first, and figuring out what the user wants and if the user has entered a valid statement.

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.

[sk5t]

Disagree with validating that sort of input in code you (the non-framework/BCL author) write; let the operators, functions, etc., do their own work of deciding if their operands are acceptable. Otherwise, where does it end--do you pre-test two integers to verify their product won't overflow the type declared for their product? I think you gotta let the exception happen.