Make modInv throw Exception on incompatible operands.

sdk/lib/core/int.dart

Index: sdk/lib/core/int.dart
diff --git a/sdk/lib/core/int.dart b/sdk/lib/core/int.dart
index 58d80b84607f5eec6965c1030ef417f6f4cc6cd5..4bac632032baa1fed7516cdd5511107f2c9e7202 100644
--- a/sdk/lib/core/int.dart
+++ b/sdk/lib/core/int.dart
@@ -116,7 +116,7 @@ abstract class int extends num {
    * modulo [modulus].
    *
    * The [modulus] must be positive.
-   * Throws a RangeError if no modular inverse exists.
+   * Throws an [UnsupportedError] if no modular inverse exists.

[regis, 2015/06/24 15:40:43]

It is an error if ...

[Lasse Reichstein Nielsen, 2015/06/25 07:22:21]

As stated elsewhere, I think we might want to tell the user how they can detect
the case where no modular inverse exists.

On the other hand, I'm leaning more and more towards returning 0 in that case
and avoid throwing. So, let's iterate this some more. The current documentation
in 1.11 leaves us free to think some more.

[regis, 2015/06/25 16:51:45]

It was my thinking in the first version, where I was returning 0 in that case,
so the user does not have to catch an exception. However, Srdjan did not like it
and I then realized that 0 is a valid answer for a modulus of 1, so I gave in
and threw in that case.

I imagine that this function will be used for crypto to choose RSA keys. The
question is whether the user will use this function to iterate and find coprime
numbers (returning -1 would be better), or will verify with other means (gcd?)
that the operands are coprime (throwing an exception is then OK).

[Lasse Reichstein Nielsen, 2015/06/30 05:50:48]

I can see that 0 can be seen as a valid answer. After all, mod 0, most equality
requiements hold. Heck, 0 is even a multiplicative unit on all the elements :)

So -1, null or throw Exception or ArithmeticException seems to be the options.

    */
   int modInverse(int modulus);