the number of frames here should already be the <= stack trace limit. as I understand it our code just provides a lower bound.

TBH this does not sound like a good idea since v8 is considering removing these non-standard APIs: https://bugs.chromium.org/p/v8/issues/detail?id=6974 By adding support in our internal error printers we are sort of encouraging people to use it - also in the case of --trace-sync-io, it is more of an implementation detail that we use the error-related API to print things.

It is especially tricky to try handling these hooks ourselves considering we also made the mistake (?) of always respecting the Error.prepareStackTrace from the main context.

@joyeecheung Yes, the API Error.stackTraceLimit itself is not standard. The idea of PR is preventing hard-coding numbers in the codebase. Either the limit shall be referred from the global Error.stackTraceLimit or just stored in the node::Environment, it would sound good to me. Since we've already used Error.stackTraceLimit multiple places, I'd think it might be fine at the time. We could remove the usage on Error.stackTraceLimit later if it's time to deprecate the API.

Anyway, if anyone has any strong opinion on this idea, it also sounds good to me if the stacktrace limit shall be referred from some internal store.

@legendecas Adding something like Environment::kStackTraceLimit SGTM. I think most internal uses of Error.stackTraceLimit are only optimizations to avoid the overhead of generating a stack trace (with the pattern of setting it to 0 or 1, creating an error, and then restoring the limit), which I don't know if is actually effective at this point considering stack trace generation in v8 is lazy.

@joyeecheung @lundibundi may I ask for your reviews on the PR since you have interests in preventing usage on the unstandardized Error.stackTraceLimit?

this code will only be in once place

There are some to be landed recently or in an expected future. #29207 and #30516. I'll update the code accordingly.

@devsnek the number of frames here should already be the <= stack trace limit. as I understand it our code just provides a lower bound.

It's true that in most cases stack trace wasn't very long to exceed the limit. Still, it is possible.

this code will only be in once place

There are some to be landed recently or in an expected future. #29207 and #30516. I'll update the code accordingly.

I meant to have one function like get_stack_size or compute_stack_size and then use it everywhere. Then we can easily just make this function return 10; if needed.

CI: https://ci.nodejs.org/job/node-test-pull-request/27884/

I agree with @addaleax and @lundibundi that the former solution seemed better. If the property will ever be removed, it's definitely possible to react to it appropriately. So far it's not likely that this is happening anytime soon.

I would not oppose to a solution that allows the JS land to configure the stack trace limit, but I would be -1 if this is Error.stackTraceLimit for the following reasons (other than it's non-standard):

1. It's an implementation detail that we use the error stack trace API to print stack traces that are not necessarily related to errors (e.g. --trace-sync-io) (actually, I don't think we currently even use the error stack trace API at all in these cases, so we'd be adding dependencies instead)
2. It's unsafe to access Error.stackTraceLimit (which can be an accessor) in some of the paths where stack traces are printed from C++ (e.g. in Environment::Exit)

CI: https://ci.nodejs.org/job/node-test-pull-request/27936/

Landed in 8baee5e 🎉