Re: Concept: Lightweight error channels

> Edmond Dantes <edmond.ht@gmail.com> hat am 28.04.2025 13:46 CEST geschrieben: > > > Hello all. > > > Yes. And even if it can be made faster (as it looks like Niels is doing, which is great), > > it will never be as fast as an empty constructor and a return. That's the level I'm > > proposing. > > If the backtrace is generated only when needed, rather than at the moment the exception is > created, there will be no difference or almost no difference (if a stack unwinding algorithm is > used). > > The total number of CPU/memory operations will be approximately the same. The only difference > is that deferred backtrace generation will require more complex frame return code, which may > introduce pitfalls. > However, if a backtrace is needed by itself, such overhead is unavoidable regardless of whether > exceptions are used or not. > > > I somewhat glossed over this point, but let me expand on it here. > > So the exception hierarchy in PHP is far from ideal. Understood. The hierarchy can be improved > to make it more logical and consistent. And as I understand it, changing the exceptions themselves > is not required for that. > > > Moreover, all exceptions currently track: > > Yes. And the main problem among them is the trace property. Neither file nor line cause > significant overhead, because file is a reference to a string constant, and line is an integer. > > > This is incorrect, as making the current exception system checked would be a ginormous BC > > break. > > And having some throwables be checked and some not, but using the same syntax and class > > hierarchy... well, that's the reason everyone detests Java's exceptions. Let's not > > do that. > > While introducing a new entity, such as a "New Error Stream" with defined contract > rules, is theoretically possible, > it would not fundamentally change the current situation. > > In practice, this approach would introduce a second category of exceptions, requiring > developers to manage: > > * the primary execution flow, > > * the standard exception flow, > > * a "special exception flow" that must be converted back into the standard one when > necessary. > > This added complexity may outweigh the potential benefits, especially given that the primary > value would be limited to preserving backward compatibility. > > It is worth carefully considering whether such a change justifies the additional mental and > technical overhead. > > On the other side of the scale: > > > > * replacing @throws with a special syntax (or perhaps simply introducing a new attribute?), > > * defining the behavior in case of contract violation while preserving backward compatibility. > > For example, if an exception contract is violated, an error would not be thrown; instead, a > warning would be issued, which would not break the program's execution flow but would help draw > the developer’s attention to the issue. > > Later in the letter you explain in more detail that this is not a special kind of exception, > nor a new execution flow, but rather a special type of result. > > But if this is a special type of result, then it should follow the same rules as all PHP types. > In other words, this cannot be solved without generics. > > However, the benefit of the new syntax, which could make the code cleaner, does not depend on > generics: > For example: > > ```php > $res = someFunction() catch ($err) {throw $err;} // Like Zig? > ``` > > But then the return type must be Throwable. > > The advantage of generics like Result<> is that they do not create a separate return > channel. > Everything operates within a single flow. > However, this approach is not yet possible in PHP. > > Introducing an additional return channel would mean increasing the overall complexity. > > Of course, this is a clean and useful syntax for such cases. > Moreover, the catch block could be made mandatory if the function is marked with a contract — > meaning the function cannot be called without a catch block at all. > > However, it seems to me that we can achieve the same result using throw, simply by adding new > syntax and capabilities. Yes, there may be some backward compatibility issues, but is it really > something to be afraid of? > Hello, looking into userland code, I often see usages for file, line, class, function, etc. without args. So there are a few options: 1) Set zend.exception_ignore_args by default to 1. 2) Add a new attribute for custom classes: #[\ExceptionSkipTraceArgs] class BreakException extends \Exception implements Exception 3) Implement a new LightException (or similar name) with no args in getTrace(). Regards Thomas