Error messages
The Rust WASM Calculator defines exactly four errors. Each one is a variant of a single Rust error type with a fixed message string, and each crosses the WebAssembly boundary as a thrown JavaScript exception that the page catches and prints to the display. There is no generic fallback, so every failure the engine can report is one of the four documented below. Two of them are reachable from the keypad; the other two are reachable only when the module is called directly from JavaScript, because the page screens those inputs out first.
Division by zero
Triggered by pressing ÷ with an operand of exactly zero. The check runs before the division, so the stored value is left unchanged and you can retry with a different operand straight away. JavaScript would return Infinity here; the calculator refuses, because Infinity propagates silently through every later operation and turns one mistake into a whole session of wrong answers.
Cannot take square root of negative number
Triggered by pressing √ with a negative value on the display. As with division, the stored value survives the error, so setting a positive value and pressing √ again works immediately. The alternative would be NaN, which compares unequal to everything including itself and is far harder to notice than a printed error.
Factorial overflow: n must be <= 20
Returned by the factorial function for any value above 20, because 21 factorial does not fit in the 64-bit unsigned integer the core computes with. The implementation checks the bound up front and additionally uses checked multiplication inside the loop, so no input can produce a wrapped result.
You will not see this one by pressing n!. The page screens the display value first and refuses anything above 20 with its own message, so the overflow error is reached only by calling the exported factorial function directly from JavaScript. See the factorial page for the reasoning behind the limit.
Invalid input: n must be a non-negative integer <= 20
Returned by the factorial function when the argument is not a whole number the function can work with: a negative value, a fractional value, or a non-finite one such as NaN or Infinity. The argument crosses the boundary as a 64-bit float rather than as an unsigned integer, precisely so that these cases arrive intact and can be rejected by name instead of being silently truncated or wrapped on the way in.
Like the overflow error, this one is screened out by the page before it can reach the module, so pressing n! with a bad value shows the page's own message instead. It is the error you get when calling the module directly.
The page's own message
One further message, “Error: Invalid input”, is produced by the page rather than by the WebAssembly module. It appears when n! is pressed and the display cannot be parsed as a whole number between 0 and 20 inclusive. Because it never reaches Rust, it is not one of the four error variants defined in the crate, even though its wording is similar to one of them.
- Division by zero — from the module, reachable from the keypad.
- Cannot take square root of negative number — from the module, reachable from the keypad.
- Factorial overflow: n must be <= 20 — from the module, reachable through the JavaScript API.
- Invalid input: n must be a non-negative integer <= 20 — from the module, reachable through the JavaScript API.
- Error: Invalid input — from the page, shown when n! is given a value it will not pass on.
Questions and answers
Why does dividing by zero show an error instead of Infinity?
Because Infinity propagates through every subsequent operation without complaint. The calculator checks the divisor before dividing and returns the error Division by zero, leaving the stored value unchanged so you can retry.
How many different errors can the calculator return?
Four are defined in the WebAssembly module: division by zero, square root of a negative number, factorial overflow above 20, and invalid factorial input. A fifth message is produced by the page itself when the factorial input is not a whole number between 0 and 20.
Does an error lose the value I had entered?
No. Every error check runs before the operation is performed, so the stored value is untouched and you can immediately retry with a valid input.
Why do I see the page's invalid input message instead of the module's?
Because the page screens the factorial input before calling the module. Anything that is not a whole number between 0 and 20 is rejected in JavaScript, so the module's own overflow and invalid input errors are reached only by calling the exported factorial function directly.