Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107631 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 89715 invoked from network); 22 Oct 2019 16:19:05 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 22 Oct 2019 16:19:05 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 317442C0532 for ; Tue, 22 Oct 2019 07:05:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Virus: No Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Tue, 22 Oct 2019 07:04:59 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id y12so2961813ioa.6 for ; Tue, 22 Oct 2019 07:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1z/eZwbSxqlwhfqz3vwqlRQcAktzOgw8nqPQPoAlDPY=; b=ubz+DzhWNxd81GJx3k0FNqJEm2ztOHNDQV404g4ZCCON/BW3hH20HiXNQ0tHLjFHSU gq8EqoijgNUZOiQgaDlaQHXUYJsDBYaNhgAQ11h97kC3odViHRjQGVgZcxl/AyXpptE+ /j+yc4Pg+yyxBe+RFlR9KodmKlq2jQGgXr8+9EfC11R+WzpJT2j7PIjxMK3NvgEXSOph k/8WtDfoJ5f5nmHXXd3emFnVBdM9di6To3taUP8/oD5pc6v/cnv9JlrLHv3ynXH3Beyz A8GGcVA9M5YXYtnAqZr/h0bjkNQatiJJPIcis3N9HHkfq3h042Fiyu7IRUo/IPPbT+ZH DqBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1z/eZwbSxqlwhfqz3vwqlRQcAktzOgw8nqPQPoAlDPY=; b=WL8ZiK42A4VccWgZAqJW8ZJuY/BlIh+PehBI6ZyuNSh9H6gqeosQdWp5NCS24+em4V oQdaeIucZj4Ls0QDhzHWqPLgZSyAHRbCpouHOJ3AdBrFGaa78pi4xymqVGYD6R6zWQhE WLQrOiOq0sJztC75VvbkuVNPWBynyN9pWUlXHpiqi567dANzUAQENJfvgDP2+vQb71t4 iVcm/B/qW7Y90fpgBtSqcSqTEezuDlpFmj20hXEnSBVHuLKoAu/H0OKZP2UWhju0v87X EGWaTlMYZpnbE2/cwNL0F1DOEfxc0fowi7Q99CcWckELSJCsLNMNRX6+OAf1+YUT1Yna NXzA== X-Gm-Message-State: APjAAAWN70L0PMHP+B3FnmxsR/AvQ5NnOShkAv3DHWOUETAh7jGLhOPQ +sxCHDKW9HNEm6PDdVKdmOf8B3jzs7LRaj0HQ6m9LuuA X-Google-Smtp-Source: APXvYqyJnDObgYc5vU33LunTF8WO9jc3Odiogg9PM+0aqonQ5vM8fiIr3Wq3LK09OIYGf/o+HGUFXBFRmb7bYsTtUXg= X-Received: by 2002:a5e:df0d:: with SMTP id f13mr3529757ioq.120.1571753098606; Tue, 22 Oct 2019 07:04:58 -0700 (PDT) MIME-Version: 1.0 References: <6fa02cb5-b474-4b36-4e0f-89679475e250@gmail.com> <9c1795d1-a069-f1b5-686c-7d53e39e1033@gmail.com> In-Reply-To: Date: Tue, 22 Oct 2019 15:04:46 +0100 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="0000000000001dfd6b0595804906" X-Envelope-From: Subject: Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions From: rowan.collins@gmail.com (Rowan Tommins) --0000000000001dfd6b0595804906 Content-Type: text/plain; charset="UTF-8" On Tue, 22 Oct 2019 at 14:38, Benjamin Morel wrote: > > I used this one function as an example, but I'm happy to apply my point of > view to other examples if you wish. > You have phrased this as though your point of view is different from mine, but I think you've just misunderstood it. I said: > All of these are candidates for returning false, or an error code, or an object in a particular status. That's precisely what your examples show: the functions returning false. So we're in agreement, some errors should become exceptions, others should be handled a different way, and some cases need new functions. > This proposal would be as good under the form of a new API though, but in > this case the naming should be changed to clearly differentiate both APIs. > Yes, new names is almost entirely the point of "a new API". The idea is that you don't have to recalibrate people's expectations of what fopen() does, breaking thousands of lines of existing code, nor compromise the design to minimise that impact. Instead, you say "here's a new function, it has these nice features, and handles errors in this really smooth way, please use it" - and more importantly, "here's a consistent set of functions which all work in this same way, please use them". Finally, to reiterate what's been said several times, there are definitely functions where the error cases are so "exceptional", that just throwing an exception would be perfectly fine. It's the commonly used sets of functions with a variety of different error conditions and use cases, like file handling, where more careful redesign is prudent. Regards, -- Rowan Tommins [IMSoP] --0000000000001dfd6b0595804906--