Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:90536 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33488 invoked from network); 12 Jan 2016 07:01:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jan 2016 07:01:08 -0000 X-Host-Fingerprint: 88.149.172.234 88-149-172-234.v4.ngi.it Received: from [88.149.172.234] ([88.149.172.234:14374] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C7/10-32047-1B4A4965 for ; Tue, 12 Jan 2016 02:01:06 -0500 Message-ID: To: internals@lists.php.net Date: Tue, 12 Jan 2016 08:00:46 +0100 User-Agent: tt v. 1.0.5; www.icosaedro.it/tt MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Posted-By: 88.149.172.234 Subject: Throwable::getCode() inconsistencies From: salsi@icosaedro.it (Umberto Salsi) Current situation from the manual: - Interface method Throwable::getCode() promises to return int. - The Error class and the Exception class both implement Throwable, but their constructor accepts $code as int while their getCode() method returns mixed. The reason, reveals the Exception::getCode() manual page, is that the getCode() method "Returns the exception code as integer in Exception but possibly as other type in Exception descendants (for example as string in PDOException).". Then, basically, getCode() may return anything, then it should be declared to return "mixed". Maybe is not too late to fix this mess, which is confusing for the user, impossible to validate, and basically useless (nobody knew what these int codes stand for before, now the situation is even worse). So here is my proposal: 1. Remove the getCode() method from Throwable and Error. The "error code" concept still remains in the Exception class for backward compatibility. 2. Specialized classes must define their specialized exceptions with their specialized feedback informations (error codes or whatever and respective properties and/or methods); user code that want to take advantage of the extra infos, may catch these specialized exceptions and it knows how to handle these data. 3. PDOException::getCode() returns 0 as any other class extending Exception I'm aware of, and instead it may define a PDOException::getSomethingElseFeedback() returning something useful, (and if it is only a string, the getMessage() method already fits the need). Regards, ___ /_|_\ Umberto Salsi \/_\/ www.icosaedro.it