Add functionality to get full stack trace when exceptions are thrown.

sdk/lib/core/exceptions.dart

 // Copyright (c) 2012, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 part of dart.core;
 
 // Exceptions are thrown either by the VM or from Dart code.
 
 /**
  * A marker interface implemented by all core library exceptions.
@@ skipping 49 matching lines @@
 class IllegalJSRegExpException extends FormatException {
   IllegalJSRegExpException(String pattern, String errmsg)
       : super("Illegal pattern: $pattern, $errmsg");
 }
 
 
 class IntegerDivisionByZeroException implements Exception {
   const IntegerDivisionByZeroException();
   String toString() => "IntegerDivisionByZeroException";
 }
+
+
+/**
+ * An interface implemented by all stack trace objects.
+ *
+ * A [Stacktrace] is intended to convey information to the user about the call
+ * sequence that triggered an exception.
+ *
+ * These objects are created by the runtime, it is not possible to create
+ * them programmatically.
+ */
+abstract class Stacktrace {

[nweiz, 2013/02/26 19:17:58]

This should be called "StackTrace", and its members should be "fullStackTrace"
and "stackTrace". Currently it's inconsistent with the rest of Dart.

[siva, 2013/02/27 02:21:59]

Done.

+  // Returns a String object that contains the full stack trace starting from
+  // the point where an exception has ocurred to 'main'.
+  external String get fullStacktrace;

[nweiz, 2013/02/26 19:17:58]

What's the motivation for this existing separate from "stacktrace"? As I
understand the discussion in issues 4061 and 7813, the spec says that a full
stack trace is required; it doesn't mention anything about a partial stack trace
also being required, let alone being the default. I'm also not sure why a
partial stack trace would be useful.

[siva, 2013/02/27 02:21:59]

A partial stack trace is very useful for library developers who are interested
in logging any errors encountered in their code and do not want to be bothered
by deep call chains from the callers code.
After discussion with Lars on this requirement we came up with this proposal of
providing both a full stack trace and a partial stack trace. Savvy library
developers who do not want to be bothered by deep call chains from the callers
get what they want while others get a full stack trace.

I am not sure if this needs to be specified in the Spec.

On 2013/02/26 19:17:58, nweiz wrote:

[nweiz, 2013/02/27 19:07:49]

It sounds like the partial stack trace is more of a special case than the full
stack trace. What do you think about changing the field names to "stackTrace"
and "partialStackTrace" respectively?

[siva, 2013/02/27 22:43:59]

The name partialStackTrace seems to have a negative connotation, I prefer
stackTrace and fullStackTrace as it conveys the right intent.

'special case' is subjective depending on what is considered normal :-)

On 2013/02/27 19:07:49, nweiz wrote:

+
+  // Returns a String object that contains a stack trace starting from the
+  // point where an exception has ocurred to the point where the exception
+  // is caught.
+  external String get stacktrace;

[nweiz, 2013/02/26 19:17:58]

Is this different than toString()? If so, document how; if not, document that
fact.

[siva, 2013/02/27 02:21:59]

Yes this different from a toString method as the toString method will get you a
full stack trace.

On 2013/02/26 19:17:58, nweiz wrote:

+}