> > > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
