Uncaught Promise rejections were made fatal and for the most part go
ignored when they fail intermittently. I'm not a huge fan of adding more
ways for tests to fail if people aren't willing to actually do something
about it when they do.
-Ryan
On 6/5/2015 6:08 AM, David Rajchenbach-Teller wrote:
My patch introduces a new Warnings mechanism for JS. If this works
nicely, I'd like to extend this to C++.
Basically, whenever you encounter a situation that should never happen
in production but that is not quite fatal enough to warrant a crash, we
call (from the top of my head)
Warnings.warn("the module that triggered the warning",
`Hey, I still have ${n} splines to reticulate, I should have 0.`);
By default, this causes tests to fail. However, tests that are designed
to cause this kind of warning can whitelist the warning with
Assert.expect("the module that triggered the warning",
/Hey, I still have [0-9]* splines to reticulate, I should have 0./)
(note the regexp)
and tests that are known to cause this kind of warning can graylist it
until the warning has been fixed
Assert.FIXME("the module that triggered the warning"
/Hey, I still have [0-9]* splines to reticulate, I should have 0./)
(also a regexp)
This API covers all the needs I have encountered for warnings so far in
JS code. I don't think it's terribly different in C++ code.
Cheers,
David
On 05/06/15 00:14, Ehsan Akhgari wrote:
Families of warnings? I don't really understand what you mean. Also,
looking at the patch in the bug, your changes seem to affect Assert.jsm
stuff, which is not related to NS_WARNING.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
