binding: Introduces ExceptionToPromiseScope.

binding: Introduces ExceptionToPromiseScope.

ExceptionState is now a scope-like object, and guarantees
that an exception is automatically thrown at destruction.
ExceptionToPromiseScope similarly guarantees to return
a reject promise instead of throwing an exception.

A new Jinja2 filter "format_remove_duplicates" helps
write a template more easily without caring duplicates.
    {% if A_enabled %}
    ScriptState* scriptState = ...;
    A(scriptState);
    {% endif %}
    {% if B_enabled %}
    ScriptState* scriptState = ...;
    B(scriptState);
    {% endif %}
produces two lines of definitions of |scriptState|,
however, format_remove_duplicates removes the duplicates.

Jinja2 macro "propagate_error_with_exception_state" is no
longer necessary, because ExceptionState and
ExceptionToPromiseScope automatically throws an exception
or returns a reject promise appropriately.

This CL alone does not fix crbug.com/627309 , but the CL
makes it easy to fix the issue.

BUG=627309
Committed: https://crrev.com/afb9da1a91b0d1742a765b7a35f27e1be6645596
Cr-Commit-Position: refs/heads/master@{#418513}

[Yuki, 2016-09-01 13:50:46]

The CQ bit was checked by yukishiino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-01 13:50:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-01 13:56:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-01 13:56:56]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Yuki, 2016-09-02 13:15:15]

The CQ bit was checked by yukishiino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-02 13:15:27]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Yuki, 2016-09-02 13:52:30]

Description was changed from

==========
binding: Introduces ExceptionToPromiseScope.

BUG=
==========

to

==========
binding: Introduces ExceptionToPromiseScope.

ExceptionState is now a scope-like object, and guarantees
that an exception is automatically thrown at destruction.
ExceptionToPromiseScope similarly guarantees to return
a reject promise instead of throwing an exception.

A new Jinja2 filter "format_remove_duplicates" helps
write a template more easily without caring duplicates.
    {% if A_enabled %}
    ScriptState* scriptState = ...;
    A(scriptState);
    {% endif %}
    {% if B_enabled %}
    ScriptState* scriptState = ...;
    B(scriptState);
    {% endif %}
produces two lines of definitions of |scriptState|,
however, format_remove_duplicates removes the duplicates.

Jinja2 macro "propagate_error_with_exception_state" is no
longer necessary, because ExceptionState and
ExceptionToPromiseScope automatically throws an exception
or returns a reject promise appropriately.

Utility functions to throw an arity error are moved from
V8Binding.h to GeneratedCodeHelper.h .

This CL alone does not fix crbug.com/627309 , but the CL
makes it easy to fix the issue.

BUG=627309
==========

[Yuki, 2016-09-02 13:52:54]

yukishiino@chromium.org changed reviewers:
+ haraken@chromium.org

[Yuki, 2016-09-02 13:52:55]

Could you review this CL?

[commit-bot: I haz the power, 2016-09-02 14:51:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-02 14:51:05]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[haraken, 2016-09-02 16:24:13]

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.cpp (right):

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.cpp:30: void
throwMinimumArityError(ExceptionState& exceptionState, unsigned expected,
unsigned actual)

These helper functions are just one line, so I'd prefer inlining them in the
call sites.

Even if we want to have the helper functions, I want to avoid putting it in
GeneratedCodeHelper since it's used in hand-written bindings as well. (I still
don't understand what GeneratedCodeHelper is.)

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h (right):

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h:41: class
CORE_EXPORT ExceptionToPromiseScope {

I still don't understand what GeneratedCodeHelper is for.
ExceptionToPromiseScope is currently used only auto-generated files but it can
potentially be used by general bindings (just like ExceptionState). It would
make more sense to put it to ExceptionState.h or something.

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h:44:
ExceptionToPromiseScope(const v8::FunctionCallbackInfo<v8::Value>& info,
ScriptState* scriptState, ExceptionState& exceptionState)

Would it make more sense to introduce another constructor of ExceptionState
(which takes care of promises) instead of introducing ExceptionToPromiseScope?

ExceptionToPromiseScope sounds like a family of ExceptionState to me.

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/templates/methods.cpp (right):

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/templates/methods.cpp:7: 'ScriptState*
scriptState = ']) %}

Honestly speaking, I'm neutral about this formatter though. It looks adding
another extra mystery to the temprate files.

Is the formatter going to be widely useful in the template files? Then it might
be worth introducing it.

[Yuki, 2016-09-05 07:19:25]

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.cpp (right):

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.cpp:30: void
throwMinimumArityError(ExceptionState& exceptionState, unsigned expected,
unsigned actual)
On 2016/09/02 16:24:13, haraken wrote:
> 
> These helper functions are just one line, so I'd prefer inlining them in the
> call sites.

I think we'd like to guarantee the following things.
- Arity error is a TypeError.
- The error message is the same among all APIs.

These helpers are useful to make sure of those things.


> Even if we want to have the helper functions, I want to avoid putting it in
> GeneratedCodeHelper since it's used in hand-written bindings as well. (I still
> don't understand what GeneratedCodeHelper is.)

Do you think V8XxxCustom.cpp is out of scope?

Otherwise, all the clients are generated bindings, and no one in core/ or
modules/ use these helpers, or I don't expect such use cases in future.

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h (right):

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h:41: class
CORE_EXPORT ExceptionToPromiseScope {
On 2016/09/02 16:24:13, haraken wrote:
> I still don't understand what GeneratedCodeHelper is for.
> ExceptionToPromiseScope is currently used only auto-generated files but it can
> potentially be used by general bindings (just like ExceptionState). It would
> make more sense to put it to ExceptionState.h or something.

I don't expect that this will be used in such a manner.  There should be no
reason to use this utility outside generated bindings.

It's strange, meaningless, inefficient, and even danger to nest
ExceptionToPromiseScope, and we'd like to have this utility at very beginning of
callback functions.  So, there should be no chance for other code to use this.

The reason why I put this utility here is because I don't want people to abuse
this utility without understanding what happens.

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h:44:
ExceptionToPromiseScope(const v8::FunctionCallbackInfo<v8::Value>& info,
ScriptState* scriptState, ExceptionState& exceptionState)
On 2016/09/02 16:24:13, haraken wrote:
> Would it make more sense to introduce another constructor of ExceptionState
> (which takes care of promises) instead of introducing ExceptionToPromiseScope?

I don't think so.  ExceptionToPromiseScope depends on v8::FunctionCallbackInfo
and a ScriptState.  We don't want ExceptionState to depend on such things.

> ExceptionToPromiseScope sounds like a family of ExceptionState to me.

No.  ExceptionState is a general purpose utility.  The purpose of
ExceptionToPromiseScope is to implement Web IDL 4.6.7. > the fuction's behavior
1. > exception case > 1.

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/templates/methods.cpp (right):

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/templates/methods.cpp:7: 'ScriptState*
scriptState = ']) %}
On 2016/09/02 16:24:13, haraken wrote:
> 
> Honestly speaking, I'm neutral about this formatter though. It looks adding
> another extra mystery to the temprate files.
> 
> Is the formatter going to be widely useful in the template files? Then it
might
> be worth introducing it.

I'm not sure what is the best way, but we definitely need something that solves
this problem.  There are a lot of clients of this formatter.  However, I'd like
to experiment this formatter with a few examples if it really works well or not.
 If it looks promising, then I'm going to use this more widely.

[haraken, 2016-09-05 08:24:22]

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.cpp (right):

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.cpp:30: void
throwMinimumArityError(ExceptionState& exceptionState, unsigned expected,
unsigned actual)
On 2016/09/05 07:19:25, Yuki wrote:
> On 2016/09/02 16:24:13, haraken wrote:
> > 
> > These helper functions are just one line, so I'd prefer inlining them in the
> > call sites.
> 
> I think we'd like to guarantee the following things.
> - Arity error is a TypeError.
> - The error message is the same among all APIs.
> 
> These helpers are useful to make sure of those things.
> 
> 
> > Even if we want to have the helper functions, I want to avoid putting it in
> > GeneratedCodeHelper since it's used in hand-written bindings as well. (I
still
> > don't understand what GeneratedCodeHelper is.)
> 
> Do you think V8XxxCustom.cpp is out of scope?
> 
> Otherwise, all the clients are generated bindings, and no one in core/ or
> modules/ use these helpers, or I don't expect such use cases in future.

I don't know. Even if we adopt your definition of generated bindings, I don't
see much benefit of distinguishing helper classes for generated bindings vs.
non-generated bindings.

Tangentically related, but Onion Soup is going to move core/modules-independent
parts of bindings/ into platform/.

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h (right):

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h:41: class
CORE_EXPORT ExceptionToPromiseScope {
On 2016/09/05 07:19:25, Yuki wrote:
> On 2016/09/02 16:24:13, haraken wrote:
> > I still don't understand what GeneratedCodeHelper is for.
> > ExceptionToPromiseScope is currently used only auto-generated files but it
can
> > potentially be used by general bindings (just like ExceptionState). It would
> > make more sense to put it to ExceptionState.h or something.
> 
> I don't expect that this will be used in such a manner.  There should be no
> reason to use this utility outside generated bindings.
> 
> It's strange, meaningless, inefficient, and even danger to nest
> ExceptionToPromiseScope, and we'd like to have this utility at very beginning
of
> callback functions.  So, there should be no chance for other code to use this.
> 
> The reason why I put this utility here is because I don't want people to abuse
> this utility without understanding what happens.

I'm confused...

Note that the logic ExceptionToPromiseScope provides is already used in multiple
places in non-generated bindings. For example,
PaymentRequest::onUpdatePaymentDetails implements the logic with
TrackExceptionState. Permissions::query implements the logic with
ExceptionState::reject.

I'm not sure how useful it is to introduce another helper class only for
generated bindings...

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h:44:
ExceptionToPromiseScope(const v8::FunctionCallbackInfo<v8::Value>& info,
ScriptState* scriptState, ExceptionState& exceptionState)
On 2016/09/05 07:19:25, Yuki wrote:
> On 2016/09/02 16:24:13, haraken wrote:
> > Would it make more sense to introduce another constructor of ExceptionState
> > (which takes care of promises) instead of introducing
ExceptionToPromiseScope?
> 
> I don't think so.  ExceptionToPromiseScope depends on v8::FunctionCallbackInfo
> and a ScriptState.  We don't want ExceptionState to depend on such things.
> 
> > ExceptionToPromiseScope sounds like a family of ExceptionState to me.
> 
> No.  ExceptionState is a general purpose utility.  The purpose of
> ExceptionToPromiseScope is to implement Web IDL 4.6.7. > the fuction's
behavior
> 1. > exception case > 1.

As I mentioned above, this functionality is implemented by TrackExceptionState
or ExceptionState::reject in non-generated bindings.

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/templates/methods.cpp (right):

https://codereview.chromium.org/2301993002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/templates/methods.cpp:7: 'ScriptState*
scriptState = ']) %}
On 2016/09/05 07:19:25, Yuki wrote:
> On 2016/09/02 16:24:13, haraken wrote:
> > 
> > Honestly speaking, I'm neutral about this formatter though. It looks adding
> > another extra mystery to the temprate files.
> > 
> > Is the formatter going to be widely useful in the template files? Then it
> might
> > be worth introducing it.
> 
> I'm not sure what is the best way, but we definitely need something that
solves
> this problem.  There are a lot of clients of this formatter.  However, I'd
like
> to experiment this formatter with a few examples if it really works well or
not.
>  If it looks promising, then I'm going to use this more widely.

I won't object if you strongly want to do this, but I'm not really happy about
making refactoring that doesn't have a clear benefit...

[Yuki, 2016-09-05 13:01:33]

The CQ bit was checked by yukishiino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-05 13:01:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Yuki, 2016-09-05 13:37:02]

yukishiino@chromium.org changed reviewers:
+ bashi@chromium.org, peria@chromium.org

[commit-bot: I haz the power, 2016-09-05 14:34:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-05 14:34:39]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Yuki, 2016-09-06 13:44:31]

The CQ bit was checked by yukishiino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-06 13:44:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-06 15:18:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-06 15:18:46]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Yuki, 2016-09-08 10:50:00]

The CQ bit was checked by yukishiino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-08 10:50:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-08 12:51:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-08 12:51:55]

Dry run: This issue passed the CQ dry run.

[Yuki, 2016-09-08 13:45:30]

The CQ bit was checked by yukishiino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-08 13:45:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Yuki, 2016-09-08 15:23:39]

Description was changed from

==========
binding: Introduces ExceptionToPromiseScope.

ExceptionState is now a scope-like object, and guarantees
that an exception is automatically thrown at destruction.
ExceptionToPromiseScope similarly guarantees to return
a reject promise instead of throwing an exception.

A new Jinja2 filter "format_remove_duplicates" helps
write a template more easily without caring duplicates.
    {% if A_enabled %}
    ScriptState* scriptState = ...;
    A(scriptState);
    {% endif %}
    {% if B_enabled %}
    ScriptState* scriptState = ...;
    B(scriptState);
    {% endif %}
produces two lines of definitions of |scriptState|,
however, format_remove_duplicates removes the duplicates.

Jinja2 macro "propagate_error_with_exception_state" is no
longer necessary, because ExceptionState and
ExceptionToPromiseScope automatically throws an exception
or returns a reject promise appropriately.

Utility functions to throw an arity error are moved from
V8Binding.h to GeneratedCodeHelper.h .

This CL alone does not fix crbug.com/627309 , but the CL
makes it easy to fix the issue.

BUG=627309
==========

to

==========
binding: Introduces ExceptionToPromiseScope.

ExceptionState is now a scope-like object, and guarantees
that an exception is automatically thrown at destruction.
ExceptionToPromiseScope similarly guarantees to return
a reject promise instead of throwing an exception.

A new Jinja2 filter "format_remove_duplicates" helps
write a template more easily without caring duplicates.
    {% if A_enabled %}
    ScriptState* scriptState = ...;
    A(scriptState);
    {% endif %}
    {% if B_enabled %}
    ScriptState* scriptState = ...;
    B(scriptState);
    {% endif %}
produces two lines of definitions of |scriptState|,
however, format_remove_duplicates removes the duplicates.

Jinja2 macro "propagate_error_with_exception_state" is no
longer necessary, because ExceptionState and
ExceptionToPromiseScope automatically throws an exception
or returns a reject promise appropriately.

This CL alone does not fix crbug.com/627309 , but the CL
makes it easy to fix the issue.

BUG=627309
==========

[Yuki, 2016-09-08 15:24:04]

Could you guys take another look?

[commit-bot: I haz the power, 2016-09-08 15:27:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-08 15:27:56]

Dry run: This issue passed the CQ dry run.

[haraken, 2016-09-09 02:01:25]

LGTM

Regarding format_remove_duplicates, I'll delegate the decision to bashi-san (I'm
slightly leaning toward to the negative side but don't have any objection).

This CL contains multiple non-trivial refactorings. Consider making one
refactoring in one CL from next time.

https://codereview.chromium.org/2301993002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h (right):

https://codereview.chromium.org/2301993002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h:38:
ExceptionToPromiseScope(const v8::FunctionCallbackInfo<v8::Value>& info,
ScriptState* scriptState, ExceptionState& exceptionState)

ExceptionToPromiseRejectionScope ?

[peria, 2016-09-09 02:15:24]

This CL seems to have many changes beside the introduction; e.g. refactoring,
removing obsolete calls, and re-formatting.

I'm happy if you split them into some small CLs.

https://codereview.chromium.org/2301993002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h (right):

https://codereview.chromium.org/2301993002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/GeneratedCodeHelper.h:35: class
CORE_EXPORT ExceptionToPromiseScope {
I prefer to contain 'Reject' in this name.

https://codereview.chromium.org/2301993002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/scripts/utilities.py (right):

https://codereview.chromium.org/2301993002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/scripts/utilities.py:435: line = ''
Do we have to add an empty line?

[bashi, 2016-09-12 23:41:20]

As for format_remove_duplicates, I don't have a strong opinion and I'm OK with
this if shiino-san thinks it's better, so lgtm.

[Yuki, 2016-09-13 13:42:32]

The CQ bit was checked by yukishiino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-13 13:42:42]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-13 15:17:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-13 15:17:32]

Dry run: This issue passed the CQ dry run.

[Yuki, 2016-09-14 07:09:33]

The CQ bit was checked by yukishiino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-14 07:09:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Yuki, 2016-09-14 07:10:59]

Could you guys take another look?

Renamed the class to ExceptionToRejectPromiseScope.

https://codereview.chromium.org/2301993002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/scripts/utilities.py (right):

https://codereview.chromium.org/2301993002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/scripts/utilities.py:435: line = ''
On 2016/09/09 02:15:24, peria wrote:
> Do we have to add an empty line?

Done.

[haraken, 2016-09-14 07:12:47]

LGTM

[peria, 2016-09-14 07:16:20]

lgtm

[Yuki, 2016-09-14 07:33:33]

The CQ bit was unchecked by yukishiino@chromium.org

[Yuki, 2016-09-14 07:33:43]

The CQ bit was checked by yukishiino@chromium.org

[Yuki, 2016-09-14 07:33:44]

The patchset sent to the CQ was uploaded after l-g-t-m from bashi@chromium.org
Link to the patchset: https://codereview.chromium.org/2301993002/#ps140001
(title: "Addressed review comments (rename, empty line).")

[commit-bot: I haz the power, 2016-09-14 07:33:59]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-14 08:46:18]

Description was changed from

==========
binding: Introduces ExceptionToPromiseScope.

ExceptionState is now a scope-like object, and guarantees
that an exception is automatically thrown at destruction.
ExceptionToPromiseScope similarly guarantees to return
a reject promise instead of throwing an exception.

A new Jinja2 filter "format_remove_duplicates" helps
write a template more easily without caring duplicates.
    {% if A_enabled %}
    ScriptState* scriptState = ...;
    A(scriptState);
    {% endif %}
    {% if B_enabled %}
    ScriptState* scriptState = ...;
    B(scriptState);
    {% endif %}
produces two lines of definitions of |scriptState|,
however, format_remove_duplicates removes the duplicates.

Jinja2 macro "propagate_error_with_exception_state" is no
longer necessary, because ExceptionState and
ExceptionToPromiseScope automatically throws an exception
or returns a reject promise appropriately.

This CL alone does not fix crbug.com/627309 , but the CL
makes it easy to fix the issue.

BUG=627309
==========

to

==========
binding: Introduces ExceptionToPromiseScope.

ExceptionState is now a scope-like object, and guarantees
that an exception is automatically thrown at destruction.
ExceptionToPromiseScope similarly guarantees to return
a reject promise instead of throwing an exception.

A new Jinja2 filter "format_remove_duplicates" helps
write a template more easily without caring duplicates.
    {% if A_enabled %}
    ScriptState* scriptState = ...;
    A(scriptState);
    {% endif %}
    {% if B_enabled %}
    ScriptState* scriptState = ...;
    B(scriptState);
    {% endif %}
produces two lines of definitions of |scriptState|,
however, format_remove_duplicates removes the duplicates.

Jinja2 macro "propagate_error_with_exception_state" is no
longer necessary, because ExceptionState and
ExceptionToPromiseScope automatically throws an exception
or returns a reject promise appropriately.

This CL alone does not fix crbug.com/627309 , but the CL
makes it easy to fix the issue.

BUG=627309
==========

[commit-bot: I haz the power, 2016-09-14 08:46:20]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-09-14 08:48:24]

Description was changed from

==========
binding: Introduces ExceptionToPromiseScope.

ExceptionState is now a scope-like object, and guarantees
that an exception is automatically thrown at destruction.
ExceptionToPromiseScope similarly guarantees to return
a reject promise instead of throwing an exception.

A new Jinja2 filter "format_remove_duplicates" helps
write a template more easily without caring duplicates.
    {% if A_enabled %}
    ScriptState* scriptState = ...;
    A(scriptState);
    {% endif %}
    {% if B_enabled %}
    ScriptState* scriptState = ...;
    B(scriptState);
    {% endif %}
produces two lines of definitions of |scriptState|,
however, format_remove_duplicates removes the duplicates.

Jinja2 macro "propagate_error_with_exception_state" is no
longer necessary, because ExceptionState and
ExceptionToPromiseScope automatically throws an exception
or returns a reject promise appropriately.

This CL alone does not fix crbug.com/627309 , but the CL
makes it easy to fix the issue.

BUG=627309
==========

to

==========
binding: Introduces ExceptionToPromiseScope.

ExceptionState is now a scope-like object, and guarantees
that an exception is automatically thrown at destruction.
ExceptionToPromiseScope similarly guarantees to return
a reject promise instead of throwing an exception.

A new Jinja2 filter "format_remove_duplicates" helps
write a template more easily without caring duplicates.
    {% if A_enabled %}
    ScriptState* scriptState = ...;
    A(scriptState);
    {% endif %}
    {% if B_enabled %}
    ScriptState* scriptState = ...;
    B(scriptState);
    {% endif %}
produces two lines of definitions of |scriptState|,
however, format_remove_duplicates removes the duplicates.

Jinja2 macro "propagate_error_with_exception_state" is no
longer necessary, because ExceptionState and
ExceptionToPromiseScope automatically throws an exception
or returns a reject promise appropriately.

This CL alone does not fix crbug.com/627309 , but the CL
makes it easy to fix the issue.

BUG=627309

Committed: https://crrev.com/afb9da1a91b0d1742a765b7a35f27e1be6645596
Cr-Commit-Position: refs/heads/master@{#418513}
==========

[commit-bot: I haz the power, 2016-09-14 08:48:26]

Patchset 8 (id:??) landed as
https://crrev.com/afb9da1a91b0d1742a765b7a35f27e1be6645596
Cr-Commit-Position: refs/heads/master@{#418513}