This isn't related to the question at hand, but one of the most interesting ways to handle this was in a smalltalk app i saw, which turned the result into a custom NaN and stuffed the execution context into the variable so even if you restored it from the database, you'd know exactly where the divide by zero occurred. That's different from all the other languages where NaNs propagate but you don't know their origin.
How to handle division by zero in a language that doesn't support exceptions?
41–50 of 66 posts
Re: How to handle division by zero in a language that doesn't support exceptions?
#42I 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 in…
> 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.
Re: How to handle division by zero in a language that doesn't support exceptions?
#43NaNs are an incredibly good idea, but it turns out we really need only one.
Also, two's complement signed integers have an asymmetry that INT_MIN Therefore, I were to design a CPU today, I would add arithmetic instructions that treated INT_MIN as a NaN, thus removing the asymmetry, and giving us an integer NaN.
16 bit int values would range from -32767 to +32767, with the bit pattern now used for -32768 being NaN. You would use it for everything that isn't representable as an int (overflow, underflow, 3/2 (as opposed to 3 mod 2), etc)
Yes, that CPU would also would have instructions for doing the regular modulo 2^16 arithmetic, but 'sane ints' would help not penalize programming languages that want to do sane integer arithmetic.
Re: How to handle division by zero in a language that doesn't support exceptions?
#44What's the difference between option 3 and an exception?
Option 3 is like calling abort() in C: you can't stop it from killing the process, unlike exceptions which can be caught and handled.
But why would you want to catch and handle division by zero? Seems like the normal thing an exception should do in that case is to kill the process.
Re: How to handle division by zero in a language that doesn't support exceptions?
#45NaNs are an incredibly good idea, but it turns out we really need only one. Also, two's complement signed integers have an asymmetry that INT_MIN Therefore, I were to design a CPU today, I would add arithmetic instructions that treated INT_MIN as a NaN, thus removing the asymmetry, and giving us an integer NaN. 16 bit int values would range from -32767 to +32767, with the bit pattern now used for -32768 being NaN. Yo…
2's complement (the binary representation of numbers in a cpu) has one awesome feature, if you add two signed numbers, even if one or both are negative, you get the right answer. This means that you can add two numbers without checking if one is negative, saving time and scarce circuit space. In order to add a NaN, you'd need a check for NaN. This would basically double the amount of time an add would take, and add more circuit paths to the core of the cpu.
If we use a single bit dedicated to signalling NaN, the overhead might be worth it. Of course, we lose half of our range in doing so.
Re: How to handle division by zero in a language that doesn't support exceptions?
#46Sounds to me like a language targeted at novice developers (and I suppose with that author means people with no programming background) should add a very strong emphasis on simulations and notifications.
Won't it be ok that program crashes if :
1. it was likely the error was catch during a simulation before deployment
2. author of code received a mail immediately to let know something bad occurred
Such a language should probably be much bigger than our usual programming language and include at core what is usually added by dev tools (tests and notifications).
There was a discussion on HN a few days ago on "test only development" (link has been marked "dead" since then, though), that is tests that produce code. It reminds me of what "programming" a holodeck looks like in star trek : you describe what you want and computer manage to produce code that achieves it.
Without getting so far, you could ask your users to describe what data looks like in input and what it should looks like on ouput, as a core feature of the language rather than on a separated and optional layer. Then, on build, you run a "simulation" (yes, that is just testing) to ensure code behaves as expected.
And you build notifications (by mail, for exemple) as a core feature of the language too, maybe even include version control (you have to think hard how to make that user friendly for your target) in order everybody has a idea of what changed before the crash (this could be reported in notification).
When you have all of that, it does not matter if division by zero makes program crash.
Re: How to handle division by zero in a language that doesn't support exceptions?
#47result, err := x / y if err != nil { do something }
Since you are using go syntax... I don't think that this will work in go, because division by zero will cause the function to panic.
Re: How to handle division by zero in a language that doesn't support exceptions?
#48NaNs are an incredibly good idea, but it turns out we really need only one. Also, two's complement signed integers have an asymmetry that INT_MIN Therefore, I were to design a CPU today, I would add arithmetic instructions that treated INT_MIN as a NaN, thus removing the asymmetry, and giving us an integer NaN. 16 bit int values would range from -32767 to +32767, with the bit pattern now used for -32768 being NaN. Yo…
2's complement (the binary representation of numbers in a cpu) has one awesome feature, if you add two signed numbers, even if one or both are negative, you get the right answer. This means that you can add two numbers without checking if one is negative, saving time and scarce circuit space. In order to add a NaN, you'd need a check for NaN. This would basically double the amount of time an add would take, and add m…
It wouldn't double the amount of time for an add (or any other operation), if it's implemented in hardware the comparison can be done in parallel with the addition, and the result of the addition ignored at the end if the compare returned true.
It would increase the use of space by the circuit, but not by much. And we already have circuitry doing similar things to set the flags (zero, carry, overflow, parity...).
If you want a real-world system with a single extra bit for every value (on registers at least), see the Itanium and its NaT bit (used for speculative loads).
Re: How to handle division by zero in a language that doesn't support exceptions?
#49Earlier quoted context omitted.
2's complement (the binary representation of numbers in a cpu) has one awesome feature, if you add two signed numbers, even if one or both are negative, you get the right answer. This means that you can add two numbers without checking if one is negative, saving time and scarce circuit space. In order to add a NaN, you'd need a check for NaN. This would basically double the amount of time an add would take, and add m…
It wouldn't double the amount of time for an add (or any other operation), if it's implemented in hardware the comparison can be done in parallel with the addition, and the result of the addition ignored at the end if the compare returned true. It would increase the use of space by the circuit, but not by much. And we already have circuitry doing similar things to set the flags (zero, carry, overflow, parity...). If…
After writing it, I realised that you could just do both in parallel, but it soon makes things much more complicated since nearly everything is based on adds.
Re: How to handle division by zero in a language that doesn't support exceptions?
#50NaNs are an incredibly good idea, but it turns out we really need only one. Also, two's complement signed integers have an asymmetry that INT_MIN Therefore, I were to design a CPU today, I would add arithmetic instructions that treated INT_MIN as a NaN, thus removing the asymmetry, and giving us an integer NaN. 16 bit int values would range from -32767 to +32767, with the bit pattern now used for -32768 being NaN. Yo…
See also: http://blog.regehr.org/archives/642