Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117968 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 33624 invoked from network); 16 Jun 2022 13:55:34 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jun 2022 13:55:34 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8340D180384 for ; Thu, 16 Jun 2022 08:43:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS63949 45.79.64.0/19 X-Spam-Virus: No X-Envelope-From: Received: from mail.salesfunnelmachine.com (mail.salesfunnelmachine.com [45.79.87.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 16 Jun 2022 08:43:34 -0700 (PDT) Received: from mail.salesfunnelmachine.com (mail.salesfunnelmachine.com [127.0.0.1]) by mail.salesfunnelmachine.com (Postfix) with ESMTP id 4LP6062GDczKtgy for ; Thu, 16 Jun 2022 15:43:34 +0000 (UTC) Authentication-Results: mail.salesfunnelmachine.com (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=salesfunnelmachine.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= salesfunnelmachine.com; h=content-transfer-encoding:content-type :in-reply-to:subject:from:references:to:content-language :user-agent:mime-version:date:message-id; s=dkim; t=1655394207; x=1657986208; bh=o4LtmKbGy4m4Cy8DxsmuUAn04UkOI39Z8O5RzL02B7E=; b= nvo47cnCsp+p/2KVW7lF+NU4va/wV03rvEhsXy2a+/Qokrk0zxjWWRzG6H2D0nox lNroAX8Q737wT7ekwxBiOqrCNeiskamy5FrXwL5HE8iPBbcfV7nQOwxvpOcVNt74 GyZaZ39iS937AFM7ETla3xqZwKLg3FF68zJUxHTMoDs= X-Virus-Scanned: Debian amavisd-new at mail.salesfunnelmachine.com Received: from mail.salesfunnelmachine.com ([127.0.0.1]) by mail.salesfunnelmachine.com (mail.salesfunnelmachine.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FKn0ylhFJegO for ; Thu, 16 Jun 2022 15:43:27 +0000 (UTC) Received: from [192.168.0.148] (unknown [172.110.168.213]) by mail.salesfunnelmachine.com (Postfix) with ESMTPSA id 4LP5zy6G2yzKtkV for ; Thu, 16 Jun 2022 15:43:26 +0000 (UTC) Message-ID: <25239658-0120-389b-20fb-1e96f827d697@systasis.co> Date: Thu, 16 Jun 2022 08:43:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: internals@lists.php.net References: <64c92c40-c180-0ea2-9b24-ec61b46640ab@bastelstu.be> Disposition-Notification-To: Jeffrey Chimene In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements From: jeff@systasis.co (Jeffrey Chimene) On 6/16/22 07:26, Robert Landers wrote: > On Thu, Jun 16, 2022 at 3:07 PM Kamil Tekiela 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