<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian Plesner Hansen wrote :<!----><br>
<blockquote
 cite="mid:d54e663b0908172223w5fcae4c5kc50ea9ad92ef0f6b@mail.gmail.com"
 type="cite">
  <pre wrap="">I think this is a nice approach[1] but would require language surgery.
 I would prefer an approach that aligns more closely with existing
implementations.  </pre>
</blockquote>
Hm, yes. A backwards compatible approach might be better indeed.<br>
I liked the syntax though, but as current implementations treat it as a
syntax error, it seems it can't be helped...<br>
<br>
David-Sarah Hopwood wrote:<br>
<blockquote type="cite">
  <pre wrap="">It would be possible to compile both optimized and deoptimized versions
of each function, and check in the optimized version whether it is in the
dynamic scope of such a 'try' block. (Actually, there's no need to restrict
it to 'try' blocks if doing that.) However, that would still add the
overhead of the check to the entry code for all optimized (and not inlined)
functions. I think it would be an overspecification to require any such
feature.

As Christian says, we might define a common interface for implementations
that do want to support this, but I don't think it requires changes to
language syntax. A 'runWithMoreDebugInfo(someFunction)' API would suffice.</pre>
</blockquote>
Indeed.<br>
Also, on second thought, using syntax for this detailed / not detailed
choice may not be the most flexible approach.<br>
<br>
Before your mail, I thought of using a specific function to use before
the given
try statement instead:<br>
<br>
&nbsp;&nbsp;&nbsp; Error.detailNextTry( true );<br>
&nbsp;&nbsp;&nbsp; try{ ... }<br>
&nbsp;&nbsp;&nbsp; catch( e ){ ... }<br>
<br>
...But it feels like a hack. Your solution is indeed more elegant and
flexible.<br>
Dunno why I got obsessed with this try statement. ^^;<br>
<br>
Christian Plesner Hansen wrote :<br>
<blockquote
 cite="mid:d54e663b0908172223w5fcae4c5kc50ea9ad92ef0f6b@mail.gmail.com"
 type="cite">
  <pre wrap="">Error.captureStackTrace(e) creates a .stack property on e that returns
the stack trace as a string when accessed.  Error.getStackTrace()
returns a StackTrace object that describes the stack and whose
toString yields a formatted stack trace string.

Error.captureStackTrace is a pretty limited and inflexible interface
but consistent with how .stack works in other implementations.  If you
set the .stack property of your error to the StackTrace object
returned by Error.getStackTrace, which was what I had in mind, you get
a more clean and flexible model but code that can already handle stack
traces may not be able to take advantage of it, for instance if it
uses "typeof e.stack == 'string'" to check if a stack trace is
present.
  </pre>
</blockquote>
I don't know if there is that much legacy code like that.<br>
Currently, AFAIK every implementation has a different way to get a
stack trace, and every browser gives different info formated in
different ways in those strings, so you have to parse it differently
anyway... So unless we follow exactly what one of those existing
browsers do, users will have to adapt their code to use it anyways...<br>
I would really prefer the Error.getStackTrace approach, it is as you
say more flexible, and doesn't alter the error object. And if someone
really wants the behavior of captureStackTrace, implementing it herself
using getStackTrace should be straightforward.<br>
<br>
Regards,<br>
<br>
Jordan OSETE<br>
<br>
</body>
</html>