Re: Feature request: https://github.com/php/php-src/issues/13301

1. Do some benchmark with ``` <?php function a($a, $b) { return $a + $b; } function aa($a, $b) { throw new \Exception(); return $a + $b; } $bag = []; $mt = microtime(true); for ($i = 0; $i < 100000; $i++) { try { a(1,2); // float(0.0023398399353027) // aa(1, 2); // float(0.053406953811646), what 25 times slower? } catch (\Throwable $e) { $bag[] = $e; } } var_dump(microtime(true) - $mt); ``` 2. Your function is a closed case then. Any error inside that case disables the whole function. So the function should be as small as possible, also possible repair/fallback/saga functions should be written. The OOP idea is "the object prepares himself (from inside), or with services (from outside)". Getters/Setters is bad because only the object should know what's happening inside. Using exceptions you have to write super-micro functions and split your logic to hundreds of methods, because any of them could fall with exceptions. And if you write a Facade that calls one function, each from that calls 10-15 internal functions - exactly that facade should decide what to do with any occurred exception. There are cases you CANNOT decide without third-party libraries. So you can't write facades and you should break the encapsulation by doing small methods instead of useful ones. That's why exceptions are not a solution. Exceptions are a validation case and a safe-shield (reporting to email) for cases you didn't cover because of a lot of work.