On Sat, Sep 14, 2019 at 6:50 AM Boris Zbarsky wrote:
> That means not using the following when throwing nsresults/DOMExceptions:
>
>ErrorResult::Throw(nsresult)
>ErrorResult::operator=(nsresult)
>
> and instead using:
>
>ErrorResult::ThrowDOMException(nsresult, const nsACString&)
>
> w
On 9/14/19 4:38 PM, David Teller wrote:
Does this have any impact on SpiderMonkey error handling?
It does not; this is purely about errors thrown through bindings or
other ErrorResult consumers in Gecko.
In SpiderMonkey, errors are typically thrown via the
(JS_)ReportErrorNumber* APIs or vi
This is excellent!
I’ll add some messages for the WebXR API.
Cheers.
- Kip
> On Sep 15, 2019, at 5:38 AM, David Teller wrote:
>
> Very good news!
>
> Does this have any impact on SpiderMonkey error handling?
>
> Cheers,
> David
>
>> On 14/09/2019 06:47, Boris Zbarsky wrote:
>> Hello,
>>
Very good news!
Does this have any impact on SpiderMonkey error handling?
Cheers,
David
On 14/09/2019 06:47, Boris Zbarsky wrote:
> Hello,
>
> ErrorResult has two kinds of exception-throwing APIs on it: the older
> ones that don't allow specifying a custom message string, and newer ones
> that
Hello,
ErrorResult has two kinds of exception-throwing APIs on it: the older
ones that don't allow specifying a custom message string, and newer ones
that do. People should use the newer ones where possible.
That means not using the following when throwing nsresults/DOMExceptions:
ErrorRe
5 matches
Mail list logo