<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class="webkit-block-placeholder"></div><div class="">Note that we are talking about API misuse here, so associating the crash with a test is not really needed - it's the test that you are writing.</div><div class=""><br class=""></div><div class="">I've seen tests getting checked in even when they don't run to completion and raise JS exceptions. I want it to be very clear and obvious when a test is bad, and a console log is too subtle of a clue. Additionally, I don't really see much difference between these asserts that we use in TestRunner and asserts in shipping code. Both are about unexpected conditions, so if we want to avoid crashing, shouldn't we also convert all ASSERTs into log messages?</div><div class=""><br class=""></div><div class="">Ultimately, I don't think that it is fair to think about testRunner and tests themselves as separate entities, which is of course the way we think about WebKit and web content. Tests are designed with testRunner limitations in mind, and if these limitations are not respected, the response should be the same as for any expectation mismatch between C++ functions. Making the connection weaker will make it harder to maintain the tests.</div><div class=""><br class=""></div><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">- Alexey</div><div class=""><br class=""></div></div><br class="Apple-interchange-newline">
</div>
<div><blockquote type="cite" class=""><div class="">23 сент. 2016 г., в 16:26, Geoffrey Garen <<a href="mailto:ggaren@apple.com" class="">ggaren@apple.com</a>> написал(а):</div><br class="Apple-interchange-newline"><div class=""><div class="">I vote for throwing a JS exception.<br class=""><br class="">In my experience, tests that crash are harder to deal with than tests that throw JS exceptions. A backtrace is a less informative than the message “you called internals.X without a frame”. Symbolication takes a long time. And sometimes we have trouble associating crash logs with specific tests.<br class=""><br class="">Geoff<br class=""><br class=""><blockquote type="cite" class="">On Sep 23, 2016, at 2:25 PM, Ryosuke Niwa <<a href="mailto:rniwa@webkit.org" class="">rniwa@webkit.org</a>> wrote:<br class=""><br class="">Hi all,<br class=""><br class="">In <a href="https://bugs.webkit.org/show_bug.cgi?id=161919" class="">https://bugs.webkit.org/show_bug.cgi?id=161919</a>, a question was<br class="">raised as to what would be the best practice when one of internals or<br class="">testRunner method is called at an undesirable timing or wrong<br class="">arguments. The case in question was about calling it on a document<br class="">without a frame when the method required a frame.<br class=""><br class="">What would be the desired outcome of making such a method call?<br class="">Should we be asserting it and crashing the process? Or should we be<br class="">throwing an exception?<br class=""><br class="">- R. Niwa<br class="">_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br class=""></blockquote><br class="">_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br class=""></div></div></blockquote></div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div></div></div></body></html>