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.
