On 6/16/22 07:26, Robert Landers wrote:
On Thu, Jun 16, 2022 at 3:07 PM Kamil Tekiela <tekiela...@gmail.com> wrote:
First of all, thank you for working on this. I wanted OO API for Curl for a
long time.
Exceptions all the way. Code that's not using exceptions is usually more
clunky and error-prone. The new OO API shouldn't have the possibility to
return null/false on error. This is considered a thing of the past nowadays
and the majority of developers prefer exceptions on error.
Please do not add any more procedural APIs. The existing ones should be
deprecated and removed at some point in the future.
Regards
Kamil
This is considered a thing of the past nowadays
and the majority of developers prefer exceptions on error.
This is certainly not true. A nice thing about errors in returns vs.
an exception is that you don't need to react to the error immediately
or abandon the current flow of the code by jumping out of it. I feel
like I see a lot of devs using exceptions for flow control instead of
actually exceptional behavior. A bad URL is probably exceptional -- if
it's actually malformed vs. something the parser just doesn't
understand yet, such as a new scheme -- while a failed connection is
almost certainly not, that's just TCP doing its thing and should be
expected in most circumstances.
-- Rob
IMNSHO, php is far more similar to basic than c. php longs to be c, but
because it's an interpreter, it can never be c. This discussion is
interesting in that it reflects the collision of interpreted code and
objects.
1. ON ERROR GOTO was as reprehensible in basic as longjmp in c. That's
why local error handling was gradually adopted in basic, and so should
it be for php.
2. The days of returning null or false on constructor error are long
behind us. Such implementation reflects php's interpreter aspect. In the
OO world, constructors shouldn't return a nugatory object on failure.
They should resignal the failure, and the coder should handle the error
locally to ease the technical debt. Branch on value rather than branch
on exception should be in the rear view mirror.
3. re: "...using exceptions for flow control instead of actually
exceptional behavior..." It's not the language's responsibility to be a
nanny. That's why we use IDEs instead of EDT
Thanks for reading,
jec
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
