Re: [webkit-dev] Asserting versus throwing in internals and testRunner objects

[Alexey Proskuryakov]

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.

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?

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.

- Alexey


> 23 сент. 2016 г., в 16:26, Geoffrey Garen  написал(а):
> 
> I vote for throwing a JS exception.
> 
> 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.
> 
> Geoff
> 
>> On Sep 23, 2016, at 2:25 PM, Ryosuke Niwa  wrote:
>> 
>> Hi all,
>> 
>> In https://bugs.webkit.org/show_bug.cgi?id=161919, a question was
>> raised as to what would be the best practice when one of internals or
>> testRunner method is called at an undesirable timing or wrong
>> arguments.  The case in question was about calling it on a document
>> without a frame when the method required a frame.
>> 
>> What would be the desired outcome of making such a method call?
>> Should we be asserting it and crashing the process?  Or should we be
>> throwing an exception?
>> 
>> - R. Niwa
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Asserting versus throwing in internals and testRunner objects

[Geoffrey Garen]

I vote for throwing a JS exception.

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.

Geoff

> On Sep 23, 2016, at 2:25 PM, Ryosuke Niwa  wrote:
> 
> Hi all,
> 
> In https://bugs.webkit.org/show_bug.cgi?id=161919, a question was
> raised as to what would be the best practice when one of internals or
> testRunner method is called at an undesirable timing or wrong
> arguments.  The case in question was about calling it on a document
> without a frame when the method required a frame.
> 
> What would be the desired outcome of making such a method call?
> Should we be asserting it and crashing the process?  Or should we be
> throwing an exception?
> 
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev