Question: Is it possible to identify possible errors for an operation from the JSON files?

[stroiman]

I'm working on a "small" project, a headless browser in Go with an embedded v8; and I've started using this project as a source to generate Go code. So far, primarily v8 wrapper on top of native Go implementations.

For this purpose, I'd very much like to know if each operation can result in an error, particularly because of how idiomatic error handling in Go works.

I am consuming files from webref/curated/idlparsed, e.g. for the URL type, I consume webref/curated/idlparsed/url.json (I assume this is a good source for this use case?).

The URL constructor can throw a TypeError, and that information is in prose in curated/algorithms/url.json, but I wasn't able to find that information in a more precise manner.

Is that information available in easy-to-consume machine readable format?

[tidoust]

I am consuming files from webref/curated/idlparsed, e.g. for the URL type, I consume webref/curated/idlparsed/url.json (I assume this is a good source for this use case?).

Yes, or the IDL extracts directly from webref/curated/idl if you prefer to use your own Web IDL parser. The curated branch is the right place to look at, in any case!

Is that information available in easy-to-consume machine readable format?

I'm afraid it isn't.

There is no standard way to express that information in Web IDL. See whatwg/webidl#603 for a proposal to annotate Web IDL definitions that may throw (but it would not give you the type of errors being thrown as far as I can tell), also wasm-bindgen/wasm-bindgen#2983 where you'll find part of the discussion and manually maintained Web IDL fragments annotated with custom extended attributes.

Specifications do define that information in prose. It may be possible to extract that prose and create machine readable extracts out of it. That likely requires a bit of work on an on-going basis (similar to what we do for CSS and IDL extracts), including working with editors to converge on common prose constructs to express the information in the specs. I don't think we're going to jump on it ourselves for lack of time, but if you're interested in digging this up further, we'd certainly be happy to help!

[stroiman]

Thanks a lot for taking the time to answer, and expressing being happy to help.

For now, I will just handle this in generator code, having a data structure that can provide options to override default behaviour for specific attributes/operations. This is useful for other purposes as well, generating "Not implemented" errors, or disabling the generator for a specific method, where I'd rather like to write the code by hand, e.g. for some functions with multiple signatures.

At the moment, I only need a boolean value, if a method can result in an error. The type of error isn't relevant yet.