Remove uses of deprecated toWebCoreStringWithUndefinedOrNullCheck(v8::Handle<v8::Value>)

Remove uses of deprecated toWebCoreStringWithUndefinedOrNullCheck(v8::Handle<v8::Value>)

Remove uses of deprecated toWebCoreStringWithUndefinedOrNullCheck(v8::Handle<v8::Value>) and
use V8TRYCATCH_FOR_V8STRINGRESOURCE*() macros instead so that we return early if an exception
is thrown by v8::String::ToString().

R=haraken

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=163492

[haraken, 2013-12-10 00:27:32]

LGTM

[commit-bot: I haz the power, 2013-12-10 02:26:07]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/110663003/1

[commit-bot: I haz the power, 2013-12-10 04:03:13]

Change committed as 163492

[pfeldman, 2013-12-10 06:33:41]

Hey guys, I don't really like the change - it makes code less readable, bloats
generated code, violates protocol error reporting convensions (there are no
unknown errors, error message does not end with punctuation). Could you roll it
out or follow up?

Could we keep a convenience method that wraps string extraction? Programming
with macros is not nice.

[haraken, 2013-12-10 06:56:38]

On 2013/12/10 06:33:41, pfeldman wrote:
> Hey guys, I don't really like the change - it makes code less readable, bloats
> generated code, violates protocol error reporting convensions (there are no
> unknown errors, error message does not end with punctuation). Could you roll
it
> out or follow up?
> 
> Could we keep a convenience method that wraps string extraction? Programming
> with macros is not nice.

This change is for correctness. If toString() throws an exception, we have to
return immediately. The macro does the work (We cannot do this kind of
early-return in a method). Does inspector expect different behavior from this?

I agree that V8TRYCATCH_FOR_V8STRINGRESOURCE_VOID is unreadable, so we might
want to rename it ToV8String() or something better.

[pfeldman, 2013-12-10 07:49:34]

A revert of this CL has been created in
https://codereview.chromium.org/98853012/ by pfeldman@chromium.org.

The reason for reverting is: The new code is unreadable..

[haraken, 2013-12-10 07:52:12]

On 2013/12/10 07:49:34, pfeldman wrote:
> A revert of this CL has been created in
> https://codereview.chromium.org/98853012/ by mailto:pfeldman@chromium.org.
> 
> The reason for reverting is: The new code is unreadable..

Would you answer the question I asked in comment #6? The original CL is for
correctness.

[pfeldman, 2013-12-10 09:37:05]

Could you instead start with filing a bug and explaining the rationale? I'll be
happy to review the patch then.

[haraken, 2013-12-10 09:45:51]

On 2013/12/10 09:37:05, pfeldman wrote:
> Could you instead start with filing a bug and explaining the rationale? I'll
be
> happy to review the patch then.

christophie: Would you mind filing a bug with some spec link? (Probably this
one: http://www.w3.org/TR/WebIDL/#dfn-overload-resolution-algorithm)