Ensure 'raises' clauses on operations are saved in IDL database.

Ensure 'raises' clauses on operations are saved in IDL database.


BUG=
TEST=

Committed: https://code.google.com/p/dart/source/detail?r=4117

[sra1, 2012-02-10 06:17:42]

Hi Pavel,

You made a similar change to support exceptions on attribute getters and
setters.
I want the information in order to mark the DOM exception types as possibly
entering Dart code via raised exceptions.
Do you know from your work in the C++ generator(s) if this information is at all
accurate?  I suspect it is not 100% accurate because of the typos indicate the
name is unused by the generator, but is there some minimum I can assume, e.g.
operations without a raise clause throw only the regular JS exceptions like
TypeError?

[sra1, 2012-02-10 06:19:10]

tbr

[podivilov, 2012-02-10 14:01:31]

LGTM.

On 2012/02/10 06:17:42, sra1 wrote:
> Hi Pavel,
> 
> You made a similar change to support exceptions on attribute getters and
> setters.
> I want the information in order to mark the DOM exception types as possibly
> entering Dart code via raised exceptions.
> Do you know from your work in the C++ generator(s) if this information is at
all
> accurate?  I suspect it is not 100% accurate because of the typos indicate the
> name is unused by the generator, but is there some minimum I can assume, e.g.
> operations without a raise clause throw only the regular JS exceptions like
> TypeError?

Presence of raises keyword indicates that webcore implementation takes
additional ExceptionCode parameter which is converted to DOMException by
generated bindings in case of failure. It is 100% accurate because otherwise c++
code won't even compile. And yes, operations without a raise could only raise
TypeError.

AFAIK exception name doesn't mean anything, which explains the typos. I also
faced this problem when generating native bindings with dartgenerator.py, we
need to fix it upstream.