Re: Errors: throw vs return

Hi Ryan,

Yes, we can wordsmith this in Last Call. I'll move the return-an-error
definition to the Terminology section. It's certainly clear now that the
promise gets rejected with a DOMException and not null, which was the
decision we wanted to make before Last Call according to our call Monday.

We've had a try ... catch model for a long time, but we could certainly
change it.

The one consideration is that some operations get called from multiple
methods - and potentially some from other operations. We would need to
decide if it is ever necessary for a caller to catch the error from a
callee and do something other then reject the promise with that error ? I
don't think we have that now, but will we never have that ?

It should be simpler, now, to global-change the "return an error" rather
than manually changing all 300+ of them as I just did ...

...Mark


On Thu, Mar 6, 2014 at 5:01 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
>
> On Wed, Mar 5, 2014 at 3:59 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>> All,
>>
>> Our SubtleCrypto methods do *not* "throw" errors. Instead we call the
>> reject handler of the promise with the error object (to be a DOMException
>> according to the other thread).
>>
>> My question is how we should describe termination with errors in the
>> asynchronous substeps and the steps of the operations. We could say:
>>
>> "Return a SyntaxError"
>>
>> or
>>
>> "Throw a SyntaxError"
>>
>> In either case we need to make the Step 4 or each method clearer:
>>
>> "4. If the following steps or the steps of invoked operations
>> (throw|return) an error, perform the following sub-steps and terminate this
>> algorithm"
>>
>> Since we might invoke other web platform procedures - like WebIDL type
>> conversion for example - which "throw" errors - perhaps we should use the
>> throw terminology in our procedures (and handle it in Step 4 of the method
>> procedures). Step 4 is like the "try ... catch ... " around all the
>> operations and other referenced procedures below.
>>
>> Thoughts ?
>>
>> ...Mark
>>
>
> So, I'm not exactly sure this is much clearer, nor do I believe the spec
> is correct.
>
> For example, your new language for Step 4 seems to redefine what it means
> to "return an error" in some sort of scope, except that scope is not
> linguistically clear.
>
> It's also unclear why "return an error" was placed in Section 14, rather
> than in the Terminology section, with all the other spec linguistic
> conventions.
>
> I'm wondering if it's clearer to say that "resolver" is passed to the
> operation (eg: Step 9 in verify, Step 8 in digest), and then let the
> individual operation use linguistic shorthand, something like
>
> "When this specification says reject <resolver> with a <name> exception,
> the user agent must perform perform the following steps:
>   1. Let <resolver> be the promise's associated resolver
>   2. Let <code> be zero.
>   3. If <name> is in the first column of the error names table and has a
> corresponding legacy code exception field value in the third column, set
> code to that value.
>   4. Run <resolver>'s reject(value) operation, with value as a new
> DOMException exception, whose message is a user-agent defined value, name
> is <name>, and whose code exception field is <code>."
>
> Within the top-level definitions for the operations (section 14)
>
>  1. "If [bad condition], reject <resolver> with a Foo exception and abort
> these steps"
>  2. "If [other bad condition], reject <resolver> with a Bar exception and
> abort these steps"
>  3. "Let result be the result of performing the [insert operation]
> operation specified by normalizedAlgorithm ..."
>  4. "If the "reject resolver with a name exception" algorithms aborted the
> operation, then abort these steps"
>
> That is, I'm not a fan of the "try/catch"
>
> In the above examples, I drew from the following specifications and the
> terminology they utilize:
> -
> http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#kill-a-worker
> - http://dom.spec.whatwg.org/#exception-domexception
> -
> https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
> - http://dev.w3.org/2006/webapi/FileAPI/
> - http://dev.w3.org/html5/spec-preview/dynamic-markup-insertion.html
>
>
>
>