Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46569 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5405 invoked from network); 29 Dec 2009 10:25:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Dec 2009 10:25:53 -0000 X-Host-Fingerprint: 188.62.49.6 6-49.62-188.cust.bluewin.ch Received: from [188.62.49.6] ([188.62.49.6:9763] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C1/D3-26502-139D93B4 for ; Tue, 29 Dec 2009 05:25:53 -0500 Message-ID: To: internals@lists.php.net Date: Tue, 29 Dec 2009 11:25:47 +0100 User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Posted-By: 188.62.49.6 Subject: Errors, Exceptions et al From: hp@oeri.ch (Hans-Peter Oeri) Hi! Although I'm new here and I know I'm about to stir up a hornets' nest, please allow me to introduce another error/exception proposal. The problem for me as a php end-user currently is, that no coherent error behaviour in php exists. Core functions only issue errors, intl eg. suppresses all errors (if not enabled), pdo allows suppressing errors, exceptions and errors - but only of level E_WARNING. Whether I prefer suppressing errors, errors or exceptions, I always run into problems: - If I prefer suppressing errors, I cannot do so with any granularity; always setting an resetting the error reporting functions is cumbersome and messy (error-prone). - If I prefer errors, I have to take care of extensions that default on suppressing them (like intl) with probably different methods of enabling errors (ini or per object or...) and frankly, I cannot count on the error level. - If I prefer exceptions, much of php doesn't support them at all and extensions might have different facilities to enable them. ErrorException is not really a solution, as exception information (exception class, previous exception) is lost. I therefore propose to let the *user* decide on the kind of error behaviour; and with some granularity at that. An extension would only ever call a common error function, with at least error code and error message (plus desired error_level and exception class if needed), whereas the "error configuration" not only decides on whether showing the error (now) but also if it is an error or an exception (new). For more details, please have a look at: http://wiki.php.net/rfc/enhanced_error_handling (which is by no means complete or error free itself) Regards HPO