Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46570 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78373 invoked from network); 30 Dec 2009 13:08:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Dec 2009 13:08:25 -0000 Authentication-Results: pb1.pair.com header.from=cschneid@cschneid.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=cschneid@cschneid.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain cschneid.com from 195.226.6.51 cause and error) X-PHP-List-Original-Sender: cschneid@cschneid.com X-Host-Fingerprint: 195.226.6.51 darkcity.gna.ch Linux 2.6 Received: from [195.226.6.51] ([195.226.6.51:40859] helo=mail.gna.ch) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 16/B6-30992-6C05B3B4 for ; Wed, 30 Dec 2009 08:08:23 -0500 Received: from localhost (localhost [127.0.0.1]) by darkcity.gna.ch (Postfix) with ESMTP id C44DB355AE; Wed, 30 Dec 2009 14:08:19 +0100 (CET) X-Virus-Scanned: amavisd-new at gna.ch Received: from mail.gna.ch ([127.0.0.1]) by localhost (gna.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiXoXYPYkWsY; Wed, 30 Dec 2009 14:08:19 +0100 (CET) Received: from [192.168.1.72] (gw-search.cyberlink.ch [212.55.194.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 23D51355AD; Wed, 30 Dec 2009 14:08:19 +0100 (CET) Message-ID: <4B3B50C2.8080500@cschneid.com> Date: Wed, 30 Dec 2009 14:08:18 +0100 User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Hans-Peter Oeri CC: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Errors, Exceptions et al From: cschneid@cschneid.com (Christian Schneider) Hans-Peter Oeri wrote: > 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 To be honest I prefer an inconsistent but stable error mechanism. Allowing to change the error behaviour (e.g. something as extreme as allowing to convert all internal errors to exceptions via ini setting - I know that's not part of this proposal, just using it as an example) leads to another inconsistency: Depending on the hosting provider and/or frameworks/modules used you'd have to write different error handlers. Suppose you want to write an open source application which has to work on all different kind of environments: It seems to me that making error behaviour configurable would make things harder rather than easier. One of the nice things about PHP it's easy to learn and knowledge & code is (most of the time) transferable amongst different instances of PHP. Regards, - Chris