RE: Bug 24813 - Decide whether methods should return DOMError or null on failure

I can think of a couple of things that might be useful to signal back to a
caller, some more for debugging than others:

 

1.       This algorithm is not supported by this platform

2.       This algorithm is not currently enabled by this platform.

3.       You had an error in the input parameters.

 

I don't know what the set of values that exist for DOMError are, so I can't
really assign specific values to these conditions.  I would agree that a
generic error should be returned in the event that the specification does
not specify a more specific error be returned to signal a specific error.

 

Note that we lost a number of error return conditions when we made
everything become asynchronous.

 

Jim

 

 

From: Mark Watson [mailto:watsonm@netflix.com] 

Sent: Friday, February 28, 2014 8:54 AM

To: Ryan Sleevi

Cc: public-webcrypto@w3.org

Subject: Re: Bug 24813 - Decide whether methods should return DOMError or
null on failure

 

No, I'm just trying to wake up the mailing list on this and the other bugs
since they are (still) not getting copied.

 

In the absence of a proposal my suggestion would be to resolve this in favor
of the existing text in which the promise is rejected with null.

 

...Mark

 

On Fri, Feb 28, 2014 at 8:47 AM, Ryan Sleevi <sleevi@google.com> wrote:

Are you making a proposal for what the errors should be?

That was and remains what's missing - someone to demonstrate value in having
discrete errors by making a proposal.

On Feb 28, 2014 8:44 AM, "Mark Watson" <watsonm@netflix.com> wrote:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24813

 

Opinions ?

 

...Mark