- From: <bugzilla@jessica.w3.org>
- Date: Tue, 13 May 2014 14:19:19 +0000
- To: public-script-coord@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25457 --- Comment #13 from Domenic Denicola <domenic@domenicdenicola.com> --- I'm sorry, I still don't understand. Functions can either return values or throw exceptions. Async functions can either return fulfilled promises or return rejected promises. When you throw an exception, you can throw anything, e.g. `throw 5`. This is bad practice though, and you generally try to throw things that are `instanceof Error` so that e.g. consumers can get stack traces. Similarly, when you reject a promise with an exception, you can reject with anything, e.g. `return Promise.reject(5)`. Again this is bad practice, and you should generally reject with things that are `instanceof Error`. There are no "restrictions" in the promise case that do not appear for every function, ever: your function can either succeed or fail, and if it fails, it _should_ do so using Error instances. Why are these semantics---which are fairly basic to JavaScript, and indeed to most imperative languages---too restrictive to implement requestAutocomplete? -- You are receiving this mail because: You are on the CC list for the bug.
Received on Tuesday, 13 May 2014 14:19:22 UTC