Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117967 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 27885 invoked from network); 16 Jun 2022 12:38:42 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jun 2022 12:38:42 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5B4A7180384 for ; Thu, 16 Jun 2022 07:26:43 -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=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,MISSING_HEADERS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-oo1-f51.google.com (mail-oo1-f51.google.com [209.85.161.51]) (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 07:26:43 -0700 (PDT) Received: by mail-oo1-f51.google.com with SMTP id o13-20020a4a84cd000000b0041161ec8419so281485oog.6 for ; Thu, 16 Jun 2022 07:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=5/CwztjUKtehYRiKwl5XFxrMYwUI7nBAr1Aj73/sMFM=; b=UmB2ZEDb5+OTQnuGQbVvBOUL/Hsc+YIoYW2RbeU8wh5tbhZ2b+3dny6+lHFtVNGgI9 yFLEwioxzD6odslNOc8cJFGq9U0hFnrJfWNBZBs5udwRpo8PlRNSewmQXBzeQNpOwI14 dnyL+d0mNB+4+Wk/QooH6yVX5DYHbFgW/xlHzwioQ9S4jEd63ssQL5fTtnVpAvCNo+To 2sEj8IEFYyspJzZ5Okex/KHNjXS2/a/Ov6CQpW8rl7OcGBV656j8n+cqvQuvZSDmPrcc kVTvHE54tthaQkUbhhfVy2Jxca9Fm5ltMO5/rFnk5+X8ashdWK/yPODXZ/CBHC4TLU9J V72Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=5/CwztjUKtehYRiKwl5XFxrMYwUI7nBAr1Aj73/sMFM=; b=4UJT2SYttHj7W2Ui2EuZJ3D99F7FZ6lqSCevLkDMkVF4LROv/stKBk/mJM55yIZnPx NXV3j0ptTyIRcGB6/cxH3q9f6yfqrCjckP0cYJGMzzTRWQvSOh0qOxggrP8W96kYteXy 9n3pBGzon4Un4Lc44FT4MQAri0bNl6n2wnfU18L4y0iQitGaMrZaMjKygZOZ72jSoTIl Mzg4FLfZ0S3Xz1czqSqlx8WACKADxfIiBkJFXMMjR9vqsVF0n0jxMoEIqBRrHR1rejK5 ejClUENNUkYWBbedu01okkeoqv3RwR2QJLN6JnJQlTR1bT5UZUbpiJz1PEylnS4MU7ai Nixw== X-Gm-Message-State: AJIora+hjmJMXPtMmiiB8bR34zDl6xToSIfJK6knyPIJ45TVkldAq272 3RmV8ekzHSvipis50z5cMMdxbsZF1ZGivwgplbCvEyLxj46KJw== X-Google-Smtp-Source: AGRyM1uX7DtXZ82LJTtgGIv1p6N6zv+dRQeSeHdNmHcuxc3lZVKmz0H0NNDfNti2BOKTOa8AGixg7xWKZEh/BmU8BTA= X-Received: by 2002:a4a:de89:0:b0:41c:4a0:c06d with SMTP id v9-20020a4ade89000000b0041c04a0c06dmr2102874oou.96.1655389602003; Thu, 16 Jun 2022 07:26:42 -0700 (PDT) MIME-Version: 1.0 References: <64c92c40-c180-0ea2-9b24-ec61b46640ab@bastelstu.be> In-Reply-To: Date: Thu, 16 Jun 2022 16:26:30 +0200 Message-ID: Cc: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements From: landers.robert@gmail.com (Robert Landers) 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