Re: Errors: throw vs return

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