> I have already demonstrated how it can be solved without generics.
Multiple response channels from a function already exist: Normal returns
and exceptions. Exceptions as currently designed are just very poorly
suited to the problem space I am describing.
If another error channel is introduced, PHP would end up with *two error
channels*.
This is harder to understand than the Normal returns + Exception channels +
Something new.
It seems to me that this creates a bigger problem than the one it is trying
to solve.
Is it possible to avoid creating two error channels and instead design an
alternative handling method that would eliminate the drawbacks of the first
approach?
If the performance issue is solved, are the other two problems really worth
such changes?
For example, if we follow the philosophy of RESULT<X>, we can say that
there are two types of exception handling cases:
1.
Suppressing an exception immediately at the first level of function call.
2.
Stack unwinding.
For example, the expression:
```php
function someFunction(): string raises SomeException {
throw SomeException()
}
// The backtrace is not generated:
$res = try someFunction() catch (SomeException) null;
// The backtrace is generated when throw $err executed.
$res = try someFunction() catch ($err) {throw $err};
// The backtrace is generated
$res = someFunction();
```
This kind of behavior doesn’t break BC, right? At the same time, it allows
improving PHP performance and adding contracts.
