22522 2013-06-30 18:46:06 +0000 WebIDL, error handling, and promises 2014-01-28 23:37:40 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC All RESOLVED FIXED P2 normal --- 1 w3c cam annevk bzbarsky d erights jackalmage marcosscaceres mike public-script-coord w3c waldron.rick public-webapps-bugzilla oldest_to_newest 90042 0 w3c 2013-06-30 18:46:06 +0000 When using a method that vends a promise, it's not clear to me what should happen when WebIDL says to throw a TypeError. The WebIDL spec should include something like: "If return type is Promise, and an exception has been thrown, instead return a rejected promise with that exception." See email thread: http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0772.html 90049 1 annevk 2013-07-01 09:00:34 +0000 Maybe it would make sense for IDL to define promises until they're integrated into JavaScript. That way it can avoid a dependency on DOM and I'll have to do less work. 90050 2 marcosscaceres 2013-07-01 10:41:04 +0000 That seems like a waste of time, tbh... why doesn't Promises just get housed in some TC-39 document (like with the internationalization stuff)? Then it can just be implemented whenever and doesn't need to be part of any ES version. The WebIDL can just reference it from there. 90051 3 annevk 2013-07-01 10:48:08 +0000 Well it does depend on HTML's event loop. JavaScript doesn't define such a thing anywhere. 90055 4 w3c 2013-07-01 14:34:32 +0000 (In reply to comment #3) > Well it does depend on HTML's event loop. JavaScript doesn't define such a > thing anywhere. That sounds like more reason to push it down the stack :) If the largest consumers of JS (Web/Node) both depend on the loop, this might encourage them to standardize it... which would be great as standardizing the event loop might provide an API to hook into it properly (instead of using setTimeout and matchMedia hacks). 90064 5 jackalmage 2013-07-01 16:36:09 +0000 (In reply to comment #4) > (In reply to comment #3) > > Well it does depend on HTML's event loop. JavaScript doesn't define such a > > thing anywhere. > > That sounds like more reason to push it down the stack :) If the largest > consumers of JS (Web/Node) both depend on the loop, this might encourage > them to standardize it... which would be great as standardizing the event > loop might provide an API to hook into it properly (instead of using > setTimeout and matchMedia hacks). TC39 is already planning to standardize the event loop in ES7, I believe. They don't need any further encouragement from us. 90074 6 marcosscaceres 2013-07-01 18:32:33 +0000 (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Well it does depend on HTML's event loop. JavaScript doesn't define such a > > > thing anywhere. > > > > That sounds like more reason to push it down the stack :) If the largest > > consumers of JS (Web/Node) both depend on the loop, this might encourage > > them to standardize it... which would be great as standardizing the event > > loop might provide an API to hook into it properly (instead of using > > setTimeout and matchMedia hacks). > > TC39 is already planning to standardize the event loop in ES7, I believe. > They don't need any further encouragement from us. <...insert Marcos + slowpoke pokemon meme here...> :) Anyway, sorry for dragging the bug off topic. 90084 7 waldron.rick 2013-07-01 21:12:54 +0000 (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Well it does depend on HTML's event loop. JavaScript doesn't define such a > > > thing anywhere. > > > > That sounds like more reason to push it down the stack :) If the largest > > consumers of JS (Web/Node) both depend on the loop, this might encourage > > them to standardize it... which would be great as standardizing the event > > loop might provide an API to hook into it properly (instead of using > > setTimeout and matchMedia hacks). > > TC39 is already planning to standardize the event loop in ES7, I believe. > They don't need any further encouragement from us. The event loop will be specified as part of ES6. 90092 8 erights 2013-07-01 22:20:45 +0000 (In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > Well it does depend on HTML's event loop. JavaScript doesn't define such a > > > > thing anywhere. > > > > > > That sounds like more reason to push it down the stack :) If the largest > > > consumers of JS (Web/Node) both depend on the loop, this might encourage > > > them to standardize it... which would be great as standardizing the event > > > loop might provide an API to hook into it properly (instead of using > > > setTimeout and matchMedia hacks). > > > > TC39 is already planning to standardize the event loop in ES7, I believe. > > They don't need any further encouragement from us. Encouragement is always appreciated ;). > > > The event loop will be specified as part of ES6. ES6 is likely only to specify the minimal placeholder of an event loop as necessary to specify module loaders. The full event loop spec is indeed likely to be in ES7. 97288 9 d 2013-12-08 07:33:14 +0000 So, we need to fix WebIDL so that whenever an error is implicitly thrown (e.g. in the overload resolution algorithm, or maybe other places) by a Promise-returning function, it needs to automatically translate that to rejecting the returned promise. E.g. if I do Promise doSomethingAsync(DOMString arg) // non-optional var p = doSomethingAsync(); then p should be a Promise rejected with a TypeError, and a TypeError should not have been thrown. Should we use this bug for tracking that? 97324 10 annevk 2013-12-09 14:38:45 +0000 I was expecting that to happen as part of bug 21422. When promises are made available as something you can use in IDL. 97325 11 annevk 2013-12-09 14:40:00 +0000 Also, this bug reads remarkably like bug 21740. 99365 12 cam 2014-01-28 23:05:56 +0000 (In reply to Anne from comment #10) > I was expecting that to happen as part of bug 21422. When promises are made > available as something you can use in IDL. I've indeed done that as part of bug 21422.