<div dir="ltr">On Thu, Oct 19, 2017 at 3:45 PM, David Teller <span dir="ltr"><<a href="mailto:dteller@mozilla.com" target="_blank">dteller@mozilla.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are you talking about tests or release?<br></blockquote><div><br></div><div>I'm not sure what "tests" and "release" refer to here.<br></div><div><br></div><div>Assuming we're in a world where uncaught errors/warnings can be turned into actionable bugs, dashboard entries, test failures, etc, we'll need an ignore list to filter out false positives. I think the best place for those to live is in the source code raising the error because attempting to define central lists is hard and quickly gets out of sync with reality. (Not sure if that answers your question.)<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="im HOEnZb"><br>
On 19/10/17 14:35, Gregory Szorc wrote:<br>
> On Thu, Oct 19, 2017 at 3:14 PM, David Teller <<a href="mailto:dteller@mozilla.com">dteller@mozilla.com</a><br>
</span><div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:dteller@mozilla.com">dteller@mozilla.com</a>>> wrote:<br>
><br>
>     Reporting through Telemetry programmer errors in our code in the wild<br>
>     will definitely help.<br>
><br>
>     For tests, it depends on whether there is someone motivated enough to<br>
>     control the whitelisting and progressive un-whitelisting. I remember how<br>
>     painful it was to push forward the<br>
>     async-errors-should-cause-<wbr>tests-to-fail when some teams seemed to expect<br>
>     that fixing errors in their code wasn't their responsibility.<br>
><br>
><br>
> Could we annotate source code with comments indicating what failures<br>
> should be ignored? This also provides a forcing function for automation<br>
> to understand source file and line mappings, which unlocks other tooling<br>
> benefits (such as automatically filing bugs in the proper component<br>
> based on the file(s) that threw the error).<br>
>  <br>
</div></div></blockquote></div><br></div></div>