Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107591 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 81807 invoked from network); 21 Oct 2019 11:27:21 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by 76.75.200.58 with SMTP; 21 Oct 2019 11:27:21 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 201CA2CA32B for ; Mon, 21 Oct 2019 02:10:59 -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=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 ; Mon, 21 Oct 2019 02:10:58 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id i26so5667738iog.9 for ; Mon, 21 Oct 2019 02:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thecodingmachine-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Kxjc/Cl+hqkSgZIntYwY8/78/4hBZAezAT3VeCAnxKY=; b=zLfL6jWmHJcNqb9wcd3c2meeohu2XhpaEBjCZ5anwd1rMQ8h3Xpr4fmZ2GKviaJ8Xg Bm/rsTTI+H6/+pr67TsNEzUf/az7YhEAT1irA7qC6MR0AQMctNNUjg4x5axb17tpl1u/ uC2hVIoauboNAg64HIzEMeNEZuxhgyksle6M4VVuD0n+mHuEtcHGM75xcaytYmboLeHm dPE7JFqYuLoglN++ne+iOdRk+SxK0z6BFLQB5JisulihcLAMVMkHpivB0MCpn+iRta/s 73aRNJFuiYoQyKLPGr33V30EcGSl98EvKvdkdX6o6ESnHDyMfc8rxokqM5A7TPT7ub1+ DjGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Kxjc/Cl+hqkSgZIntYwY8/78/4hBZAezAT3VeCAnxKY=; b=Fc89lGNX85hS7TmbJ7/TJ7lKqWRr9Sk9QC6uUbHK6Tgqzy2GRpHGOCXwqxn3mWrpd2 2MFZ4ytTNPXoPgC3optmlVTDNeKWW8++21zZMnzLflYYW+/7T9INGj/js+/8qQHfYCi4 qzShYmEhz2haFY1z85NJk/UEvtxDPny29Li2VPdjLSxuvl742SePMwjnZhoocM5mi3Yj Vt9C9bt1XnDW/3EdIIU0i/I2VqtwFlpduSqFxRnLgRf5rdhExwE0BgztcBazUNvlCtw5 5lPojf6f5ZwyZzfr88DJxubxHLMr9f7yeSc1q9P+bOTVMBTY5l9nTOC6stE8CBMPzdvu dUtg== X-Gm-Message-State: APjAAAXnzSASbxwURfht8r6unXi0lNFbYV9+rfWtlwpbviiIfzLWwTho 23an+MK3nMSw3B2iHyx7IENZtaaofu1dRC28ZEyaVFmuoJpJ6w== X-Google-Smtp-Source: APXvYqz3Tn725TDt6i7PG8eoIVG4sykKVbAu5izZUAIOSjJGPQdLGKo/TY8gALKsz3g41ovuN4wzDCl5RYBXa03DdqA= X-Received: by 2002:a6b:ba06:: with SMTP id k6mr18140316iof.76.1571649057261; Mon, 21 Oct 2019 02:10:57 -0700 (PDT) MIME-Version: 1.0 Date: Mon, 21 Oct 2019 11:10:46 +0200 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000c520ff0595680fcf" X-Envelope-From: Subject: Reclassifying some PHP functions warning as exceptions From: d.negrier@thecodingmachine.com (David Negrier) --000000000000c520ff0595680fcf Content-Type: text/plain; charset="UTF-8" Hey list, TL;DR: I'm considering writing an RFC (and a patch) to turn some warning into exceptions in a number of PHP functions. I would first like to gather some feedback here. The long version: It is the first time I'm posting on internals. Some of you may already know me. I'm one of the authors of thecodingmachine/safe, a library that wraps all PHP functions that return "false" on error in similar functions that will throw on exception on error: https://github.com/thecodingmachine/safe/ Surprisingly enough, I've had a huge positive feedback with Safe (I reached 1000 stars on Github in a few weeks, so I think I can say this is something that bothers a lot of people). Of course, I could simply have written an error handler that would turn E_WARNING into exceptions but: - For some libs, I wanted to write code that would behave consistently (whatever the settings of error_reporting) - More than all, having a return type that can be "string|false", or "object|false" is a true annoyance when you want to write type-safe code (which is more and more common with the advent of tools like PHPStan or Psalm). For instance, "sprintf" can return "string" or "false" (in case the format is incorrect). If the string passed to "sprintf" is invalid, I would certainly prefer knowing right now (with an exception) than risking having the warning sleep under my nose. Needless to say: a good practice in error handling is "fail loud, fail fast". A warning at some point will most certainly lead to an error a few lines later if error handling is not done properly. If you look at the frameworks out there, I believe all of them are shipping with an error handler that throws exceptions by default (even on notices). Also, my team and I are starting to spend a lot of time maintaining Safe. So I started wondering if rather than spending time maintaining a patch in user land, we could not instead spend time fixing things in the core. So here we are, my team and I started playing with php-src. We are not regular C developers, but we managed to write a small patch to turn "sprintf" warnings into exceptions. This is far from ready but the PR is here: https://github.com/php/php-src/pull/4837 We would be happy to promote more warnings to exceptions as those: - are more predictable - can be more easily caught / handled - enhance the type system by removing the "false" return type This is going in the same direction as Nikita RFC's regarding reclassifying "Engine Warnings". I understand there have been a lot of discussions going on recently regarding maintaining backward compatibility vs evolving/sanitizing the language and I know this is a sensitive topic. That being said: - most frameworks are already providing an error handler that turns warning into exceptions (so they should not be impacted by the change) - there are a huge number of warnings that can be turned into exceptions with minimal impact ("sprintf" E_WARNING are clearly a good first candidate) Ok, so my team and I are willing to put some time to turn some of those warnings into exceptions. I understand there are some questions to be answered regarding the nature of the exception (what class, what class hierarchy...) My questions: 1- Do you think there is a chance an RFC on this topic might be accepted? Shall I start working on it? 2- Shall we start working on a list of candidate functions? David --000000000000c520ff0595680fcf--