3 ms·
I liked the ternary operator where you provide an alternate value in case the denumerator is 0. One more idea I didn't see is to mark the variable as "invalid"
by anon4 12y ago
I liked the ternary operator where you provide an alternate value in case the denumerator is 0.
One more idea I didn't see is to mark the variable as "invalid". A general "this variable doesn't have a value because the program did something bad", which carries a full stack trace with itself. Then, if you ever use that value anywhere, the result is again invalid, with the new operation attempted on top (i.e. if the invalid value ever appears in an expression, the entire expression yields invalid and no function calls are attempted; an exception would be boolean operators - true or invalid is true and false and invalid is false - there may be other exceptions to that, too). Once that value is no longer referenced anywhere, you log a nice long description of the entire chain where things were wrong and continue business as usual. Maybe email the trace to the project lead or something.
Something like the Maybe monad basically. It will work with anything else that can fail, too, and you can allow people to construct their own invalids. And the program will continue to run as long as the error isn't too deep, which is what is really wanted here, I think.
- ori_b 12y ago> One more idea I didn't see is to mark the variable as "invalid". That's what NaN is.
- aromogato 12y agoNot quite, marking a variable as invalid in this context is essentially a job for the type system. For example, in C, you can have a void* which can be null. This can lead to seg faults, and NaN has the same pitfall. Instead, with the Maybe idea above, the type system explicitly makes you handle the NaN case since the type is a discriminated union. This is like `int?` in C#.
- ericHosick 12y agoI like the idea of providing an alternate value or even alternate flow of execution. The action to take when dividing by 0 is based on context: it is a business behavior. In my opinion, it is no different than any other business requirement (for example: passwords must be longer than 8 characters, etc.). A language should allow a developer to configure the action to take when a division by zero occurs within a given context: the default being an exception and/or termination of program execution.
- goblin89 12y ago> One more idea I didn't see is to mark the variable as "invalid". A general "this variable doesn't have a value because the program did something bad", which carries a full stack trace with itself. A simple way to handle exceptions like that (and I didn't see it mentioned among the answers) is to return 2-tuple from the function: result value and error information. The latter could be empty, but both could be present. Though this might be overcomplicating things, given that OP targets the language at novices.
- derefr 12y agoYep. You’d think that in, say, Haskell, the division operator would return Maybe Num. It’s much more obvious when you’ve got Nothing than when you’ve got NaN.