Fixes to CaughtException and AnalysisException

Fixes to CaughtException and AnalysisException

Two issues:

1. Some exceptions don't derive from Exception (for example
   NoSuchMethodError).  So to avoid problems in checked builds,
   CaughtException.exception needs to have type Object.

2. When an exception is caught by the unittest framework, it prints it
   using its toString() method.  So in order to see the stack trace of
   the CaughtException nested in an AnalysisException, we need
   AnalysisException's toString() to print both the exception and its
   cause (if any).

R=brianwilkerson@google.com, jwren@google.com, scheglov@google.com

Committed: https://code.google.com/p/dart/source/detail?r=37186

[Paul Berry, 2014-06-02 22:35:47]

An unfortunate side effect of #2 is that stack traces don't get printed in a
sensible order, because we can't control the fact that the unit testing
framework wants to print the exception string followed by its stack trace.  For
example, if a NoSuchMethodError is thrown from point A, caught at point B and
wrapped inside an AnalysisError with message m1, then caught at point C and
wrapped inside another AnalysisError with message m2, and finally caught by the
unit testing framework, the output will be:

AnalysisError: m2
Caused by m1
Stack trace for B
Caused by NoSuchMethodError
Stack trace for A
Stack trace for C (printed in a slightly different format)

The only solution I can think of for this would be to reverse the canonical
order for printing stack traces so that we get:

Analyisis Error: m2
  Caused by m1
    Caused by NoSuchMethodError
    Stack trace for A
  Stack trace for B
Stack trace for C (printed in a slightly different format)

(perhaps with indentation to help the reader follow the nesting).  But
considering that most of us are familiar with the order produced by Java, I'm
not convinced this would be any better.

[Brian Wilkerson, 2014-06-02 22:49:37]

LGTM

[scheglov, 2014-06-02 23:05:47]

lgtm

[jwren, 2014-06-03 03:20:03]

LGTM

https://codereview.chromium.org/304293010/diff/10001/pkg/analyzer/lib/src/gen...
File pkg/analyzer/lib/src/generated/java_engine.dart (right):

https://codereview.chromium.org/304293010/diff/10001/pkg/analyzer/lib/src/gen...
pkg/analyzer/lib/src/generated/java_engine.dart:265: cause._writeOn(buffer);
Is a \n inserted with writeOn?  Same question for other class.

[Paul Berry, 2014-06-10 17:15:46]

https://codereview.chromium.org/304293010/diff/10001/pkg/analyzer/lib/src/gen...
File pkg/analyzer/lib/src/generated/java_engine.dart (right):

https://codereview.chromium.org/304293010/diff/10001/pkg/analyzer/lib/src/gen...
pkg/analyzer/lib/src/generated/java_engine.dart:265: cause._writeOn(buffer);
On 2014/06/03 03:20:04, jwren wrote:
> Is a \n inserted with writeOn?  Same question for other class.

Yes.  _writeOn always ends with a call to buffer.writeln() (or a recursive call
to another _writeOn()), so a newline is inserted.

[Paul Berry, 2014-06-10 17:16:52]

Committed patchset #2 manually as r37186 (presubmit successful).