Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119181 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 50425 invoked from network); 16 Dec 2022 23:09:17 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Dec 2022 23:09:17 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1D9B71804DF for ; Fri, 16 Dec 2022 15:09:17 -0800 (PST) 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.3 required=5.0 tests=BAYES_05,SPF_HELO_PASS, SPF_NEUTRAL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS30827 82.113.144.0/20 X-Spam-Virus: No X-Envelope-From: Received: from xdebug.org (xdebug.org [82.113.146.227]) by php-smtp4.php.net (Postfix) with ESMTP for ; Fri, 16 Dec 2022 15:09:16 -0800 (PST) Received: from [127.0.0.1] (unknown [185.69.145.0]) by xdebug.org (Postfix) with ESMTPSA id D07EB10C02C; Fri, 16 Dec 2022 23:09:15 +0000 (GMT) Date: Fri, 16 Dec 2022 23:09:14 +0000 To: Theodore Brown , PHP Developers Mailing List User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <0E149CE3-9124-4473-92FE-ABF11B585C77@php.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [Vote] More Appropriate Date/Time Exceptions From: derick@php.net (Derick Rethans) On 16 December 2022 21:34:16 GMT, Theodore Brown = wrote: >On Thu, Dec 15, 2022 at 8:27 AM Derick Rethans wrote: > >> Hi, >>=20 >> I've just opened the vote for "More Appropriate Date/Time Exceptions"= =2E >> It runs until December 31st, 24:00 UTC=2E >>=20 >> You can vote at: >> https://wiki=2Ephp=2Enet/rfc/datetime-exceptions#voting > >Hi Derick, > >Thank you for your work on this=2E I like the idea of having more specifi= c >exceptions to avoid having to parse generic exception/warning strings=2E > >However, I voted No because there doesn't seem to be an implementation >currently, and I'm concerned about introducing differences in error >handling between the procedural and object-oriented date functions=2E > >Is there a rational for why the procedural date functions should continue >producing generic warnings/exceptions, rather than consistently using the >same exception hierarchy as the OO interface? I fear this could make it >harder for users to switch between the procedural and OO APIs, as some >errors might have to be handled in a different way=2E > >Also, could maintaining parity between the procedural/OO APIs be more >difficult if they each implement error handling differently? >Perhaps I'm mistaken, but I thought that currently the procedural date >functions are simple aliases of the corresponding object method=2E You're mistaken then=2E The procedural versions never threw exceptions, an= d changing to that now is a big BC break, which is not warranted=2E=20 It was always a deliberate choice (since 2014) that the procedural version= s don't throw exceptions, and the OO versions do=2E The RFC is not wanting = to change this behaviour=2E And rightfully so=2E=20 cheers=20 Derick=20