It probably makes sense to converge on a common string format.
However, I agree with some of the previous replies: if the main
motivation for standardising stack traces is to make them processable,
then we should focus on introducing a structured format.
/Andreas
On 12 November 2013 21:33,
On 11/12/13 11:07 PM, David Bruant wrote:
I understand the need to know when a promise has an unhandled error at
development time, I'm less clear on why you need to know it at runtime.
Why would you do with this information? handle the error?
The same thing that sites (e.g. Facebook) do with
On Tue, Nov 12, 2013 at 8:07 PM, David Bruant bruan...@gmail.com wrote:
Le 12/11/2013 13:42, Kris Kowal a écrit :
One of the concerns with promises is that they consume exceptions that
may or may not be handled.
...
I understand the need to know when a promise has an unhandled error at
Le 13/11/2013 06:15, Boris Zbarsky a écrit :
On 11/12/13 11:07 PM, David Bruant wrote:
I understand the need to know when a promise has an unhandled error at
development time, I'm less clear on why you need to know it at runtime.
Why would you do with this information? handle the error?
The
On 11/13/13 10:58 AM, David Bruant wrote:
I'm sympathetic with this use case, but Weakrefs seem like the wrong
tool to solve this problem.
I think I agree on that.
Ideally, the ECMAScript error sink would handled both uncaught thrown
errors and unhandled promise errors.
Defining unhandled
Le 13/11/2013 08:11, Boris Zbarsky a écrit :
On 11/13/13 10:58 AM, David Bruant wrote:
I'm sympathetic with this use case, but Weakrefs seem like the wrong
tool to solve this problem.
I think I agree on that.
Ideally, the ECMAScript error sink would handled both uncaught thrown
errors and
From: es-discuss es-discuss-boun...@mozilla.org on behalf of David Bruant
bruan...@gmail.com
Domain#intercept which looks at the Node error convention (error in async
callback first argument) certainly suffer from the same issue, but looks
practical enough. I lack the experience with Node
On Nov 13, 2013, at 7:58 AM, David Bruant wrote:
...
The browser has window.onerror for historical reasons, Node.js introduced
Domains and Domain#intercept [1] for that reason IIUC.
Isn't it the sign that ECMAScript should have this feature built-in?
A global sink has something absurd to
On Wed, Nov 13, 2013 at 8:20 AM, David Bruant bruan...@gmail.com wrote:
Le 13/11/2013 08:11, Boris Zbarsky a écrit :
On 11/13/13 10:58 AM, David Bruant wrote:
I'm sympathetic with this use case, but Weakrefs seem like the wrong
tool to solve this problem.
I think I agree on that.
On Wed, Nov 13, 2013 at 9:25 AM, Mark S. Miller erig...@google.com wrote:
On Wed, Nov 13, 2013 at 8:20 AM, David Bruant bruan...@gmail.com wrote:
Le 13/11/2013 08:11, Boris Zbarsky a écrit :
On 11/13/13 10:58 AM, David Bruant wrote:
I'm sympathetic with this use case, but Weakrefs seem
Hi Mark,
The only approximation that seems acceptable to me is one that (a) never
has false negatives, and (b) provides a simple way for developers to
receive notification on and fix false positives.
Over in Dart they have implemented zones.
http://api.dartlang.org/dart_async.html
{ zen }
The only approximation that seems acceptable to me is one that (a) never
has false negatives, and (b) provides a simple way for developers to
receive notification on and fix false positives.
Basic sysadmin stuff.
To finish the thought, `done` and `WeakRefs` fail (a), and console-only
On Nov 13, 2013, at 1:27 PM, Paul Hoffman wrote:
no hat
On Nov 13, 2013, at 12:24 PM, Joe Hildebrand (jhildebr) jhild...@cisco.com
wrote:
We would also need to change section 8.1 according to the mechanism that
was previously proposed:
00 00 00 xx UTF-32BE
00 xx ?? xx UTF-16BE
Nit: 9.1.10 [[Delete]] (P)
Steps 5 6 should be steps 4a 4b (lost an indent)
On Fri, Nov 8, 2013 at 12:25 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
PDFs and .doc file available at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#november_8_2013_draft_rev_21
Wait, so is there no variable shadowing allowed then?
13.1.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-early-errors
Static Semantics: Early Errors
Block : { StatementList }
* It is a Syntax Error if the LexicallyDeclaredNames of StatementList
On Nov 13, 2013, at 3:41 PM, Ian Halliday wrote:
Wait, so is there no variable shadowing allowed then?
this is saying that things like the following are illegal:
{var x;
let x;
}
But shadowing, like the following is fine:
var x;
{let x;
}
13.1.1 Static Semantics: Early Errors
Oh, is shadowing a let declaration with a var declaration a syntax error?
E.g.
{
let x;
{
var x;
}
}
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Ian
Halliday
Sent: Wednesday, November 13, 2013 4:14 PM
To: Allen Wirfs-Brock
Cc:
On Nov 13, 2013, at 4:18 PM, Ian Halliday wrote:
Oh, is “shadowing” a let declaration with a var declaration a syntax error?
E.g.
yes, although strictly speaking it is the hoisting of the var over the let that
is an error. Amounts to the same thing.
{
let x;
{
var
On Wed, Nov 13, 2013 at 3:51 PM, Joe Hildebrand (jhildebr)
jhild...@cisco.com wrote:
that all software implementations
which receive the un-prefixed text will not generate parse errors.
perhaps:
...all conformant software ...
Mark https://google.com/+MarkDavis
*— Il meglio è l’inimico
The draft spec has a note in 9.2.13 Function Declaration Instantiation about
arrow functions and arguments:
Issure: should concise methods also not get an arguments object?
From rev16 it appears.
Section 9.2.13 also has a large banner stating that it is old and will change
re concensus made
On Nov 13, 2013, at 3:51 PM, Joe Hildebrand (jhildebr) wrote:
On 11/13/13 3:47 PM, John Cowan co...@mercury.ccil.org wrote:
It's not clear that 404 disallows it, since 404 is defined in terms of
characters, and a BOM is not a character but an out-of-band signal.
However, for example, a
21 matches
Mail list logo
