>From that point of view you're absolutely correct. I want to use json_last_error() with global state, but with the ability to manually change the state size to prevent memory overflow.
So I suggested it because the count of bad code will grow in arithmetic progression because of the times on the Earth - firing out developers who "know the truth", hiring cheap developers who "just do". You could believe in correctness or help people who need that help. I understand that php spent many years on fast solutions, and btw, I am glad to write code with PHP, even with older versions >5.6 / >7.2, because there's exactly catched balance between "all possible" and "you need to". This `raise` is a case that will be required until somebody changes the business world. But business never changes, in the last 30 years it has become more "predatory" and unscrupulous. Getting back to the error handling problem - still no solution about "exceptions coming to warnings being called in batches/pipes/bulks" and no solution for "each exception could cause time loss on big amounts of incoming data". If you aren't gonna implement `raise` keyword (or other way like that) - at least one thing could be implemented easily - collecting error traces only if it is required, some mark, or flag, if you don't want to implement different interface that won't break/collapse the code, at least by honored SOLID separate responsibility of trace collection and error raising, to reduce timelosses. I mean - allow the developer to throw an error that just stops the code with a message, doing that the fastest way possible. Otherwise, I understand the point, and have nothing to add here.
