Change _interpolateSingle to use the same value in errors as _interpolate.

runtime/lib/string_patch.dart

Index: runtime/lib/string_patch.dart
diff --git a/runtime/lib/string_patch.dart b/runtime/lib/string_patch.dart
index f584410861cc4f8838a07be46a853edcf68e5801..bef6a18113b220038e2586435dffdef5f0c2617f 100644
--- a/runtime/lib/string_patch.dart
+++ b/runtime/lib/string_patch.dart
@@ -799,7 +799,7 @@ class _StringBase {
   static String _interpolateSingle(Object o) {
     final s = o.toString();
     if (s is! String) {
-      throw new ArgumentError(o);
+      throw new ArgumentError(s);

[Lasse Reichstein Nielsen, 2015/02/12 13:11:09]

Using "o", which we already know has a faulty toString, means that the error
can't be printed either. We used "s" in _interpolate below.

Using "s" reduces the problem (but using Error.safeToString(s)) would likely be
even better.

[Ivan Posva, 2015/02/20 06:43:48]

Since you know s is not a String, you could also use o for the safeToString
call. I am not sure how much it helps here to try to use s in the ArgumentError
as s is not the faulty argument.

[sra1, 2015/02/24 16:57:02]

It seems a bad idea to report the wrong irritant like this (e.g. null).

We would not worry about this if ArgumentError was robust and reported a bad
object for the 'message' , e.g.  "Instance of ${o.runtimeType} (with bad
toString() method)", or "unprintable object" if that fails too.

That would also help other places that throw errors with bad toString methods.

We could still report something special here.

If this throw was changed to

   throw _interpolationNotStringError(o, s);

then the helper could be called from _interpolate too to ensure consistency,
probably throwing something like ArgumentError.value(o, 'interpolated value',
'toString() method does not return a String')

     }
     return s;
   }