Dangling decorationState.[[Finished]] when throwing

[camillobruni]

If a decorator throws, we don't set decorationState.[[Finished]] = true. This means that if addInitializerClosure is used later, it can still be called without throwing which might be a bit misleading.

This applies to the two following steps:

• 15.7.6 ApplyDecoratorsToElementDefinition, step 5.h
• 15.7.7 ApplyDecoratorsToClassDefinition , step 1.c

[pzuraq]

@ljharb would this be a normative change to fix? Definitely was not the intended behavior

[ljharb]

Yes, but it doesn't seem like a controversial one.

[nicolo-ribaudo]

I also stumbled upon this in the Babel implementation, I'd love for it to be changed.

[pzuraq]

It definitely will, I'll propose it at the upcoming plenary, just needed to figure out if it was normative

[ljharb]

You could probably fit it into today’s plenary session if you’re available.

[pzuraq]

Unfortunately I am not available today, my schedule is packed at the moment 😕

[nicolo-ribaudo]

@pzuraq I can present it for you of you want (this change)

[pzuraq]

@nicolo-ribaudo I don't have a PR or slides for it unfortunately. The change is just to make the procedure that calls decorators be an explicit completion that catches the error and sets the didDecorate state to true, so it can't be called again. It's not a huge change, I just don't have time to handle it today.

[nicolo-ribaudo]

Ok well, I opened https://github.com/pzuraq/ecma262/pull/13 in the meanwhile. If you change your mind and you are ok with me presenting just ping me :) (this change is so small that the PR description is enough, it doesn't need slides).