On Wed, Apr 16, 2014 at 6:59 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> From: db...@google.com [mailto:db...@google.com] On Behalf Of Dan Beam
> > So just pass no argument at all (i.e. arguments.length == 0)?  I was
under the impression some type of value should always be returned (but I'm
biased by blink/v8's current implementation).
> It's equivalent, both for promises and for return values of functions.
Both `new Promise(resolve => resolve())` and `new Promise(resolve =>
resolve(undefined))`  give a promise whose fulfillment value is
`undefined`. In this sense `resolve` behaves like all non-evil JavaScript
functions, where evil is defined as "checking `arguments.length`" ;)

I've seen only positive feedback on this thread, so I've started
implementing in Blink.

Regarding the rejection argument: requestAutocomplete() can fail in a way
that doesn't map intuitively to the current DOMException names (e.g. the
invoking <form> has autocomplete="off" or isn't in a frame).  Adding new
names for these specific failure categories doesn't seem useful to the
platform.  Additionally, many potential failure causes may have the same
reason property[1] ("disabled" => SecurityError, WrongDocumentError?,
InvalidAccessError?)** and the terminology differs slightly ("cancel" =>

This seems confusing to web authors, so I propose a new type instead (in

 interface AutocompleteError : DOMException {
     readonly attribute DOMString reason;  // matches
AutocompleteErrorEvent's reason[1]

This new type would have a code of 0 (as other new exceptions have; code is
deprecated).  I've filed a bug to add this to the DOMException name

Dan Beam

[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25457

** names with "?" are the closest existing error names I could find (but
aren’t great)

Reply via email to