Re: [RFC] throwable_string_param_max_len: Configurable string length in getTraceAsString()
| From: | tyson andre | Date: | Sat, 27 Jun 2020 18:12:53 +0000 |
| Subject: | Re: [RFC] throwable_string_param_max_len: Configurable string length in getTraceAsString() | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-110748@lists.php.net to get a copy of this message | ||
> >
> > I've created a new RFC
> > https://wiki.php.net/rfc/throwable_string_param_max_len
>
> How come you're proposing an ini setting instead of adding a parameter
> to getTraceAsString() that specifies the length for params?
I don't expect many people to use a parameter for getTraceAsString(),
and that alternative doesn't help with implicit
__toString() or the default output
for fatal throwables.
The application developer and end user may have different ideas of what to use as a length.
If an application would manually use
getTraceAsString(Config::getMaxStringLengthForEnvironment()),
it'd be much shorter as an ini setting.
> Also, I didn't understand why there was a problem with formatting
> traces in userland. I saw a link to some code, but no clear
> description of what the problem was.
If there's an uncaught exception and no exception handler,
you'll get it truncated to 15 bytes.
Setting up a more complicated solution to format traces of uncaught traces in userland is probably
not worth the effort for short php scripts,
and many people would call getTraceAsString() over getTrace() for the convenience (especially in
rarely used code paths).
If you're an end user of an application or composer library,
patching the code to format traces in userland is inconvenient if the application developers are
using stringified exceptions or getTraceAsString().
- Tyson