-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bare Error instance does not log correctly #944
Comments
with
with
with
|
lockdown({ overrideTaming, errorTaming: 'unsafe', stackFiltering: 'verbose', consoleTaming: 'unsafe' });
console.log(Object.getOwnPropertyDescriptors(Error.prototype));
|
first |
this api may allow us to customize and fix output https://github.com/nodejs/node/blob/7633c86eebbf6e381e60e63dc6e3eb36a3cce276/lib/internal/util/inspect.js#L294-L304 |
neat hack, if you add a Object.defineProperty(err, 'constructor', { value: Error }) |
See #636 |
There is a SES bug that results in errors print printed to the console as `{}`[1]. The known workaround is to print the error stack rather than printing the error directly. This affects our build script when it is run with LavaMoat. We used this workaround in one place in the build script already, but not in the handler for task errors. We now use it in both places. The workaround has been moved to a function that we can use throughout the build script. [1]: endojs/endo#944
There is a SES bug that results in errors being printed to the console as `{}`[1]. The known workaround is to print the error stack rather than printing the error directly. This affects our build script when it is run with LavaMoat. We used this workaround in one place in the build script already, but not in the handler for task errors. We now use it in both places. The workaround has been moved to a function that we can use throughout the build script. [1]: endojs/endo#944
There is a SES bug that results in errors being printed to the console as `{}`[1]. The known workaround is to print the error stack rather than printing the error directly. This affects our build script when it is run with LavaMoat. We used this workaround in one place in the build script already, but not in the handler for task errors. We now use it in both places. The workaround has been moved to a function that we can use throughout the build script. [1]: endojs/endo#944
There is a SES bug that results in errors being printed to the console as `{}`[1]. The known workaround is to print the error stack rather than printing the error directly. This affects our build script when it is run with LavaMoat. We used this workaround in one place in the build script already, but not in the handler for task errors. We now use it in both places. The workaround has been moved to a function that we can use throughout the build script. [1]: endojs/endo#944
This comment was marked as duplicate.
This comment was marked as duplicate.
Do you have a reason to turn on |
There is a SES bug that results in errors being printed to the console as `{}`[1]. The known workaround is to print the error stack rather than printing the error directly. This affects our build script when it is run with LavaMoat. We used this workaround in one place in the build script already, but not in the handler for task errors. We now use it in both places. The workaround has been moved to a function that we can use throughout the build script. [1]: endojs/endo#944
ses: (
master
at time of writing ac1cc0)node: v14.17.6 (and v16.9.1, v17.2.0)
logs only
error stack and message are intact
previous issue #636
The text was updated successfully, but these errors were encountered: