Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110271 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 67815 invoked from network); 24 May 2020 22:27:51 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 May 2020 22:27:51 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6CECB1804DA for ; Sun, 24 May 2020 14:07:37 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS 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-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 24 May 2020 14:07:36 -0700 (PDT) Received: by mail-ej1-f51.google.com with SMTP id x20so18588619ejb.11 for ; Sun, 24 May 2020 14:07:36 -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=qaF4VauP2gAn28M7WRZBNR4nmn3uREp1HfhUa4uf/2U=; b=NmYMxox+gUPsOmZ+5yYQTZbiobLrDS4Jj2XD+aMfEnX2D0O8qKXo4q1ZnV0edt9U+r TCp91sfO8/j9gsvNFZtkuIBJ41Cpc5eZumhfQny2gVuE6lk9duUhxNhc2XNNBvdKPsPl 9Ch9nzS6sG+wHUeowmlUattTpxr5irHYp8HnIis2eNmn9C93NZwFLynoRvIhvutyVK+d te9yXHAIyv0GbW6PCFJd1XpStcFR9CYwUUiLtU+hP89YIsQSe8uLOTQW/vGTICBzllsy BEwoIvxuD5DMIDHlTxw1Ymg69ZhBcrA59g1xQvBCNfFH5+S/Uf++myA7fe2D0GdxWEGi FXzQ== 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=qaF4VauP2gAn28M7WRZBNR4nmn3uREp1HfhUa4uf/2U=; b=jX3ecVEMfzJKXdzKALokzYi/F4EyNJ/a7+orLvU+Dcks35Uzx//7s3FXIn24eDpDSq q/MauaIoK7R9lsTxn+3hJuyADpxPzM8Tv8Eh4C9cagS7WrWQw3BmLitugCW97Cn6FdIx ZbW4jPgJg91Qh7eTKwRgi0M6GKfzGYSTP/cEHnAhBNGDnL323ODXIdo+CLLT9Vd05YUi r0UBBN5QNbcA4QIZqGTK8PM0IywaK9dshaE4h73ZRsKKBRR5Tzotm4e3vWiZLT2EGL3D MZi6dMvzcVAH4ajqPyeg4UahnTWRFDVbifrINnBUHDBU3ErDpUDVE2ve7ip5ga934Fvw s8qg== X-Gm-Message-State: AOAM531QrrA5gAcckuOYc0jWYq/3Ht7ryhNBbyETpYGWcuVChLc/enoH 7e1rzYH1eiS9scOTJXyUZt7Zys54g0Q5odkhZfkBRqZvgg== X-Google-Smtp-Source: ABdhPJylcQdc183QSYdrlpz+mwRghOl6cggXwDyW/3Pgi6WqHh9wcZI0FMiw7fdcBr5PDPOxo3Ca7nyUC7wbSxvtehY= X-Received: by 2002:a17:906:1d55:: with SMTP id o21mr16006230ejh.491.1590354453048; Sun, 24 May 2020 14:07:33 -0700 (PDT) MIME-Version: 1.0 References: <0819e254-c789-e3d6-b23d-08128f195953@gmail.com> In-Reply-To: <0819e254-c789-e3d6-b23d-08128f195953@gmail.com> Date: Sun, 24 May 2020 17:07:22 -0400 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="0000000000003db3c405a66b4059" Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Error Exceptions mode From: iggyvolz@gmail.com (Katie Volz) --0000000000003db3c405a66b4059 Content-Type: text/plain; charset="UTF-8" On Fri, May 22, 2020 at 12:56 PM Rowan Tommins wrote: > Personally, I'm not a fan of promoting messages to exceptions in this > way, because APIs designed to throw exceptions generally look rather > different from ones designed to warn and continue, so blindly converting > seems like putting a square peg in a round hole. However, I know people > do it already, so will give my thoughts on the principle. > To this (and also to George's point) - I definitely agree that this isn't a perfect solution. I see this as more of a "stopgap" for people who prefer exception-style handling rather than having to do both. > My main concern is that it needs a tighter definition of "error", and > possibly a configurable one. > > The snippet from the manual which you include in your draft RFC > references the current global error_reporting setting. This makes sense > with a global error handler, but less so for a per-file declare - it > means the caller can choose whether exceptions are thrown, somewhat > defeating the point. Perhaps the declare directive could take an error > level as its argument, e.g. declare(error_exceptions=E_ALL-E_NOTICE)? > I hadn't thought putting the error types in the declare(). My only issue with that is how that would interact with the error_reporting setting - for example if I set my error_reporting to E_WARNING and error_exceptions to E_ALL I'm not sure whether a notice would be thrown. As far as a tighter definition of error - I've kept it loose in the draft as I'm not sure how exactly to define errors which can and can't be processed at runtime. For example, a compile error cannot be caught at runtime, nor can (at least in my patch) warnings which are issued before current_execute_data is populated (that is the object which I read to check if the flag is set). > Relatedly, you would need to define how this interacts with the @ (error > suppression or "shut up") operator - would that force the code to run > past a point that would otherwise throw an exception? Again, I think > that choice should be taken away from the caller, otherwise the author > needs to account for both modes, e.g. > > declare(error_exceptions=E_WARNING); > try { > $fh = fopen($blah, $mode); > // if caller can suppress ErrorExceptions, we still need to check > if $fh is false > // ... > } catch ( ErrorException $e ) { > // the caller shouldn't actually care what happens, because we can > catch it here > } > The error suppression operator should behave as you've described it. In a file with declare(), no warnings will ever be issued, meaning that a suppression operator on a function defined with the flag (or, for that matter, within such a file itself) will never have an effect. I will clarify this in the RFC as well as add a test for that case. On Fri, May 22, 2020 at 1:22 PM G. P. B. wrote: > I did a similar PoC last summer (see: > https://github.com/php/php-src/pull/4549) > where Nikita commented that a lot of those warnings could/should be > promoted > to error regardless, and this is what myself and a couple of other people > have > been during for the past year. > From what I can see your approach is slightly different than mine - this does not manually change any function's error behaviour but removes the warning system entirely. As we saw in https://wiki.php.net/rfc/engine_warnings - there is still (and may always be) significant pushback on moving errors to exceptions. As mentioned above, I see this as a "stopgap" for authors who do not want to deal with the error system in any way. --0000000000003db3c405a66b4059--