Bugzilla

Thanks @ryan! 

Just to be clear for item "3", the  `WebAssembly.Exception` is **created** in Javascript using a JavaScript function but I think you are saying that the exception will then be made available to the wasm module, which will then attach the stack track and throw it. I.e. it is thrown from WASM not javascript. Is that right?

I only ask because in item 1 you say "Exceptions thrown in WebAssembly code will not have a stackTrace property attached to them" - so it might be that the javascript function would also be passed the stack trace and then be expected to throw the exception.

I don't think that is the case, because the `stack` property is readonly, so you couldn't attach it in Javascript.

Is there any test code demonstrating this?

Thanks @ryan! 

Just to be clear for item "3", the  `WebAssembly.Exception` is **created** in Javascript using a JavaScript function but I think you are saying that the exception will then be made available to the wasm module, which will then attach the stack track and throw it. I.e. it is thrown from WASM not javascript. Is that right?

I only ask because in item 1 you say "Exceptions thrown in WebAssembly code will not have a stackTrace property attached to them" - so it might be that the javascript function would also be passed the stack trace and then be expected to throw the exception.

I don't think that is the case, because the `stack` property is readonly, so you couldn't attach it in Javascript.

Is there any test code demonstrating this?

2. What is the "point"/"value" of WebAssembly:Tag? I can see that it defines a sequence of data types, and that an exception takes this and will error if the sequence of payload data does not match the number and type in the tag. 
   - Why do we care?
   - To put it another way, when I see the word "tag" I think some marker that defines a location or a version. So this tag might be seen to identify a particular version of an Exception. In future if we decide to throw a new exception with an extra value we'd need a new tag and code would be able to differentiate the two exception types?

Thanks @ryan! 

Just to be clear for item "3", the  `WebAssembly.Exception` is **created** in Javascript using a JavaScript function but I think you are saying that the exception will then be made available to the wasm module, which will then attach the stack track and throw it. I.e. it is thrown from WASM not javascript. Is that right?

I only ask because in item 1 you say "Exceptions thrown in WebAssembly code will not have a stackTrace property attached to them" - so it might be that the javascript function would also be passed the stack trace and then be expected to throw the exception.

I don't think that is the case, because the `stack` property is readonly, so you couldn't attach it in Javascript.

Is there any test code demonstrating this?

2. What is the "point"/"value" of WebAssembly:Tag? I can see that it defines a sequence of data types, and that an exception takes this and will error if the sequence of payload data does not match the number and type in the tag. 
   - Why do we care?
   - To put it another way, when I see the word "tag" I think some marker that defines a location or a version. So this tag might be seen to identify a particular version of an Exception. In future if we decide to throw a new exception with an extra value we'd need a new tag and code would be able to differentiate the two exception types?

3. Is there a good place to ask these kinds of questions?

Thanks @ryan! 

Just to be clear for item "3", the  `WebAssembly.Exception` is **created** in Javascript using a JavaScript function but I think you are saying that the exception will then be made available to the wasm module, which will then attach the stack track and throw it. I.e. it is thrown from WASM not javascript. Is that right?

I only ask because in item 1 you say "Exceptions thrown in WebAssembly code will not have a stackTrace property attached to them" - so it might be that the javascript function would also be passed the stack trace and then be expected to throw the exception.

I don't think that is the case, because the `stack` property is readonly, so you couldn't attach it in Javascript.

Is there any test code demonstrating this?

2. What is the "point"/"value" of WebAssembly:Tag? I can see that it defines a sequence of data types, and that an exception takes this and will error if the sequence of payload data does not match the number and type in the tag. 
   - Why do we care?
   - To put it another way, when I see the word "tag" I think some marker that defines a location or a version. So this tag might be seen to identify a particular version of an Exception. In future if we decide to throw a new exception with an extra value we'd need a new tag and code would be able to differentiate the two exception types?

3. Is this a good place to ask these kinds of questions (and if not, is there a better one?)

Thanks @ryan! 

Just to be clear for item "3", the  `WebAssembly.Exception` is **created** in Javascript using a JavaScript function but I think you are saying that the exception will then be made available to the wasm module, which will then attach the stack track and throw it. I.e. it is thrown from WASM not javascript. Is that right?

I only ask because in item 1 you say "Exceptions thrown in WebAssembly code will not have a stackTrace property attached to them" - so it might be that the javascript function would also be passed the stack trace and then be expected to throw the exception.

I don't think that is the case, because the `stack` property is readonly, so you couldn't attach it in Javascript.

Is there any test code demonstrating this?

2. My inference is that 
   - before exception handling WebAssembly code would throw specific errors: [WebAssembly.CompileError](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/CompileError), [WebAssembly.LinkError](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/LinkError), [WebAssembly.RuntimeError](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/RuntimeError).
     - Note, examples are all a bit crap at those links because they appear to be thrown from javascript, and my assumption is that normally they would come from WASM code.
   - With exception handling we can now have exceptions in WASM. These are "generic" and are thrown to JS as WebAssembly:Exception.
   - These can be trapped in WASM code and rethrown.
   - These can be thrown in JS code called from WASM and caught in WASM.
   - How do these "fit in" with the "old" exceptions like  [WebAssembly.RuntimeError](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/RuntimeError) ?

3. My understanding is that 
   - a tag defines the type of exception in WASM. It just consists of a sequence of data types and an attribute. 
   - This attribute can currently just indicate "an exception thrown from javascript (or not)", but might indicate something else in future.
   - The tag is represented in JavaScript by WebAssembly:Tag, so when you create a tag you're creating a _type_ of exception.
   - A specific exception that you throw has a type e.g. a Tag, and some runtime argument. So when you create an WebAssembly.Exception you're telling WASM I have this type of exception (see the tag) and the arguments in this case are these fields.
   - So by analogy, in Javascript we might have an exception that had a error code, and a string. We can't have a string data type in WASM (I don't think) but if we could we'd define a tag that had fields for the data type of the error code and string, and an exception would take this, and the specific values for this particular instance of the type of exception.
   - I guess my problem is that "type of exception" is a bit abstract. It seems that the wasm and the javascript that calls it will have to have an intimate knowledge of each other to understand how to use the types of exceptions that they share.
   - Does any of that seem like I understand  how this works?
 
4. Is this a good place to ask these kinds of questions (and if not, is there a better one?)

Thanks @ryan! 

Just to be clear for item "3", the  `WebAssembly.Exception` is **created** in Javascript using a JavaScript function but I think you are saying that the exception will then be made available to the wasm module, which will then attach the stack track and throw it. I.e. it is thrown from WASM not javascript. Is that right?

I only ask because in item 1 you say "Exceptions thrown in WebAssembly code will not have a stackTrace property attached to them" - so it might be that the javascript function would also be passed the stack trace and then be expected to throw the exception.

I don't think that is the case, because the `stack` property is readonly, so you couldn't attach it in Javascript.

Is there any test code demonstrating this?

2. My inference is that 
   - before exception handling WebAssembly code would throw specific errors: [WebAssembly.CompileError](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/CompileError), [WebAssembly.LinkError](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/LinkError), [WebAssembly.RuntimeError](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/RuntimeError).
     - Note, examples are all a bit crap at those links because they appear to be thrown from javascript, and my assumption is that normally they would come from WASM code.
   - With exception handling we can now have exceptions in WASM. These are "generic" and are thrown to JS as WebAssembly:Exception.
   - These can be trapped in WASM code and rethrown.
   - These can be thrown in JS code called from WASM and caught in WASM.
   - How do these "fit in" with the "old" exceptions like  [WebAssembly.RuntimeError](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/RuntimeError) ?

3. My understanding is that 
   - a tag defines the _type_ or structure of exceptions in WASM. It just consists of a sequence of data types and an attribute. Its telling you that at some point an exception might be thrown that has data fields of these data-types.
   - a specific exception thrown from WASM (or JS)  has to match a tag. It will have runtime arguments with the same types/order as the associated tag.
   - The attribute can currently just indicate "an exception thrown from javascript (or not)", but might indicate something else in future. 
     - I'm a bit confused by this because I would have thought the "where is this thrown from" would belong to the runtime exception not the tag.
   - The tag is represented in JavaScript by `WebAssembly:Tag`, so when you create a tag you're creating a _type_ of exception. You have to pass this to the module so it can be actually used by WASM. 
   - The runtime exceptions is represented in Javascript using `WebAssembly.Exception`. This tells WASM I have this type of exception (see the tag) and the arguments in this case are these fields.
   - I guess my problem is that "type of exception" is a bit abstract. It seems that the wasm and the javascript that calls it will have to have an intimate knowledge of each other to understand how to use the types of exceptions that they throw.
   - Does any of the above seem like I have a broad understand  how this works?
 
4. Is this a good place to ask these kinds of questions (and if not, is there a better one?)