Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122333
MIME-Version: 1.0
References: <CAK=iT=UrMCPw5ydCnxa_87ws6xKRO5Y3qJnmchczgDds8u660A@mail.gmail.com>
 <CABigaAUjSx3-vEaQhPk-toJTSg+J3CLrO3otpm1g6hqbYyQKvw@mail.gmail.com>
 <CAK=iT=WgsEZjyu3Y2wTWvycqCsYH7MrLsZgERZK3u75U08ePpA@mail.gmail.com>
 <CAL0xaBHfEMs1BVAMZOuFCUpb9orNSRD0YDhu=3wJAGK7K0_=dg@mail.gmail.com>
 <CAK=iT=XDVcs+y4XDmGu2re137i2yD9LiEj1-HLvyxxxrb8jFUw@mail.gmail.com>
 <CAK=iT=UDUjCZ-25k_MkHFO7uKdWAqoJxdWLVBGM2_SYDk-JyAg@mail.gmail.com>
 <742f202d-7990-4f51-b903-7a15e3fd33c2@app.fastmail.com> <CABigaAW2KeGxf7HnzpcOeS=CL31=UNGZnqpZvoJsJg4miBTBGw@mail.gmail.com>
 <1cd8fa7b-ab62-4563-bf13-bb7801f1ce8d@app.fastmail.com>
In-Reply-To: <1cd8fa7b-ab62-4563-bf13-bb7801f1ce8d@app.fastmail.com>
	=?UTF-8?B?Yg==?= <6562680@gmail.com>
Date: Wed, 7 Feb 2024 20:28:58 +0300
Message-ID: <CAK=iT=X5XKdSZ1D=+SEU4=12hJK+oPn+XBWxA54yyQsxAixx8A@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000e608b90610ce0923"
Subject: Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
From: 6562680@gmail.com (=?UTF-8?B?0JPRgNC40LPQvtGA0LjQuSBTZW5pb3IgUEhQIC8g0KDQsNC30YDQsNCx0L7RgtGH0LjQuiBXZQ==?==?UTF-8?B?Yg==?=)

--000000000000e608b90610ce0923
Content-Type: text/plain; charset="UTF-8"

I still don't understand why the problem is signature and moving a simple
throw statement to return type, and then rewriting the catch statement to
oneline-r.

I am completely satisfied with the php way of working with method
signatures except non-critical cases:
- still no `undefined` type, so some functions have limited functionality
with func_num_args() inside
- no languages still implement emptiness check on argument types. empty
string should always be additionally asserted, like positive-negative
numbers, and nan/inf with float stuff (nan/inf is too rarely case)
- I'd say generics support but it is fully covered with phpdoc. use
argument Generic, mark it as class-string and @template and it works well

Try/catch statements don't scare me.

I feel the trouble in missing try/catch statements and requirements to
check all method call places once you throw a non-critical error just
because another way, sorry, necessary way, is too hard for fast
implementation. That trouble arrives only when you move from single-task
script to multi-task script. The nearest example is SQL, which always works
with rows and never returns one value, response is always "list of rows".

So the primary method of error handling should be focused on batch
processing, but `throw` keyword is very handy for filters, assertions,
validators and low level static functions.

If you finish your code fully covered with exceptions - once you try to run
several times the same with try/catch over method calls - the original
action code could have been better by catching some exceptions on its own.
However, it is closed to you and now if you want to break it into two
parts, you will have to rewrite it completely, because it is completely
closed to you and the slightest exception that was not caught in itself
(and not in you) will break it entirely, and will not disable part of it.

The exception was invented in order to shift the closure of the problem to
the next level of developers. However, it is the exception that prevents
these developers from changing the source logic of the code that throws it
and continuing to perform the action intended in the source code - the
exception simply breaks the entire branch (following `encapsulation`). This
means it should break only the most primitive functions that can be
replaced quickly. This is where the so-called SOLID came from, which forces
everything to be broken down into molecules instead of first closing the
problem and then deciding whether to break it into parts or leave it that
way.

--000000000000e608b90610ce0923--