Currently the causal console (consoleTaming: "safe") does a lot of magic. In particular it replaces error objects with the decorated error name, and separately calls console.debug with the stack and related errors and information (from assert.note), all as strings.
consoleTaming: "unsafe" is not appropriate because, some properties of the start console may reveal powers (e.g. the stdout stream in node). Furthermore because of #636, the override of Error.prototype.constructor causes node's inspect to fail and print confusing error info (#944).
I propose to separate console taming from the causal console and error restoring mechanisms. Console taming would wrap all initial console methods to leave a safe console object in compartments (as long as we trust the initial methods to not mutate the arguments). Console augmenting would have different levels:
- None: passes argument through without changing anything or making extra console calls. A virtualized console aware of SES can use the
getStackString and other note inspection powers to detail and serialize the console calls as it wishes. E.g. a plugin for sentry.
- Minimal: recreate a new error object with a
stack own property containing the untamed stack, an constructor own property to satisfy node's inspect, and potentially a cause own property to convey some of the causal capabilities of SES. We could also imagine adding a note or details own property with the details from assert.note. It would not do anything else beside substituting the tamed error objects for detailed ones.
- Causal: The current causal console logic which serializes errors and their details as multiple console calls.
Currently the causal console (
consoleTaming: "safe") does a lot of magic. In particular it replaces error objects with the decorated error name, and separately callsconsole.debugwith the stack and related errors and information (fromassert.note), all as strings.consoleTaming: "unsafe"is not appropriate because, some properties of the start console may reveal powers (e.g. thestdoutstream in node). Furthermore because of #636, the override ofError.prototype.constructorcauses node's inspect to fail and print confusing error info (#944).I propose to separate console taming from the causal console and error restoring mechanisms. Console taming would wrap all initial console methods to leave a safe console object in compartments (as long as we trust the initial methods to not mutate the arguments). Console augmenting would have different levels:
getStackStringand other note inspection powers to detail and serialize the console calls as it wishes. E.g. a plugin for sentry.stackown property containing the untamed stack, anconstructorown property to satisfy node's inspect, and potentially acauseown property to convey some of the causal capabilities of SES. We could also imagine adding anoteordetailsown property with the details fromassert.note. It would not do anything else beside substituting the tamed error objects for detailed ones.