> Edmond Dantes <[email protected]> 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