Consider the following scenario: 1. Module A prints warnings when it’s used incorrectly; 2. Module B uses module A correctly; 3. Some future refactoring of module B starts using module A incorrectly, hence displaying the warnings; 4. Nobody realizes for months, because we have too many warnings; 5. Eventually, something breaks.
How often has this happened to everyone of us? This scenario has many variants (e.g. module A changed and nobody realized that module B is now in a situation it misuses module A), but they all boil down to the same thing: runtime warnings are designed to be lost, not fixed. To make things worse, many of our warnings are not actionable, simply because we have no way of knowing where they come from – I’m looking at you, Cu.reportError. I have put together an API that could replace runtime warnings with something much more actionable, and much less noisy. They key aspects are that: - when the code is executed as part of the test suite, it causes test failures; - individual tests can whitelist individual failures; - when the code is executed on a user's computer, it does nothing costly. To avoid spamming everyone, I have put all the details on my blog: http://yoric.rajtel.name/2014/11/20/rfc-we-deserve-better-than-runtime-warnings/ Feedback would be appreciated. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
