On Thu, Feb 8, 2024 at 8:57 PM Григорий Senior PHP / Разработчик Web
<6562...@gmail.com> wrote:
>
> 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.
It's not actually 25x slower, it's only 15x slower to create an
exception. The rest of your overhead is in appending to the array
(~1ms aggregate), throwing (~10ms aggregate).
This isn't even something to worry about though, in most applications.
> 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.
I've worked on PHP (and non-PHP) applications with (tens of) millions
of lines of code, and I've never run into this problem. You write
small functions so they can be reusable, not to handle exceptions.
Generally, you don't need to do anything if you rely on types:
function add(int|float $left, int|float $right): int|float { return
$left + $right; }
will throw a TypeError if you call it with strings (at least in strict
mode, in non-strict mode, it will be coerced to a number if a numeric
string), as it should. You shouldn't even have to catch this because
it should be caught in development, and in production, it very much
should crash.
For larger functions/methods, error conditions should be guarded
against through interfaces and types, which will be caught long before
production, either in a code review or in a developer environment.
Robert Landers
Software Engineer
Utrecht NL
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
