Ambiguous wording regarding the optionality of stack tracing attachments

exception-handling/proposals/exception-handling/Exceptions.md

Lines 452 to 454 in 74e7aa6

	which can optionally contain `traceStack` entry. When `traceStack` is `true`,
	web VMs can attach a stack trace string to `Exception.stack` field, as in
	JavaScript's `Error` class. While `Exception` is not a subclass of JavaScript's

The use of "can" here makes it seem as if attaching a stack trace is optional, and possibly up to the whim of the host/engine? Can this be reworded to make it obvious as to which way it is intended to be interpreted?

[aheejin]

Yes, "can" means it is optional. It being optional is explained in more detail in the JS API section.

Yes, "can" means it is optional. It being optional is explained in more detail in the JS API section.

Can you elaborate, and/or point out any specific sentences that explain that? For clarification, the snippet that I refer to is from is in that very section that you also reference.

[aheejin]

This is the sentence that explains the optionality:

exception-handling/proposals/exception-handling/Exceptions.md

Lines 451 to 454 in 74e7aa6

	The `Exception` constructor can take an optional `ExceptionOptions` argument,
	which can optionally contain `traceStack` entry. When `traceStack` is `true`,
	web VMs can attach a stack trace string to `Exception.stack` field, as in
	JavaScript's `Error` class. While `Exception` is not a subclass of JavaScript's

Also note that the optional ExceptionOptions argument, which contains stack trace:

exception-handling/proposals/exception-handling/Exceptions.md

Lines 479 to 489 in 74e7aa6

	dictionary ExceptionOptions {
	boolean traceStack = false;
	};
	[LegacyNamespace=WebAssembly, Exposed=(Window,Worker,Worklet)]
	interface Exception {
	constructor(Tag tag, sequence<any> payload, optional ExceptionOptions options);
	any getArg(Tag tag, unsigned long index);
	boolean is(Tag tag);
	readonly attribute (DOMString or undefined) stack;
	};

I'm not certain as to whether we have the same idea in mind; I am asking whether the engine may still not attach the trace, even if traceStack is true?
E.g.,

const tag = new Tag();
const exception = new Exception(tag, [], { traceStack: true });
const did_attach_stack_trace = undefined !== exception.stack;

Here, is it possible that exception.stack is undefined, regardless of the parameter provided?
This is what I consider ambiguous by the current writing.

[aheejin]

Ah I see. Yeah, all web Wasm engines have the capability to attach stack traces, but there can be other non-web engines without that, in which case they don't need to error out; they can "not attach" stack traces. If the current wording seems unclear, I'd appreciate PRs or suggestions.

@aheejin And a quick question before I attempt a PR, to get a better understanding of this, is an engine permitted to attach the stack trace even if traceStack is false?

I believe my problem with this currently is in part that traceStack sounds like a directive, demanding that it is or isn't performed, yet it may act as more of a hint or request?

[aheejin]

@aheejin And a quick question before I attempt a PR, to get a better understanding of this, is an engine permitted to attach the stack trace even if traceStack is false?

No.

I believe my problem with this currently is in part that traceStack sounds like a directive, demanding that it is or isn't performed, yet it may act as more of a hint or request?

Request sounds the most appropriate word here. So it is like "If you have the capability, attach stack traces". If the engine can't do that it's fine not do to it.