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 do. People should use the newer ones where possible. > > That means not using the following when throwing nsresults/DOMExceptions: > > ErrorResult::Throw(nsresult) > ErrorResult::operator=(nsresult) > > and instead using: > > ErrorResult::ThrowDOMException(nsresult, const nsACString&) > > which allows passing a message string that explains why the exception is > being thrown. Web developers will thank you and not post tweets like > https://twitter.com/sebmck/status/1155709250225573889 > > When throwing TypeError or RangeError, ThrowTypeError/ThrowRangeError > already require a message string, though I am making some changes in > https://phabricator.services.mozilla.com/D45932 to make it a bit simpler > to pass in custom message strings there. > > Thank you all for making web developers' lives better, > Boris > > P.S. We currently have a _lot_ of uses of the > no-informative-error-message APIs. Some of these might be things we > don't really expect web pages to hit (e.g. exceptions when in the wrong > type of global). But generally speaking all ~560 uses of > operator=(nsresult) are code smells, as are the ~1000 uses of > Throw(NS_ERROR_DOM_*). > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform