Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9074
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <26E7D27E-8C99-11D8-8792-000393B2B3C0@omniti.com>
References: <1081740243.14476.11.camel@coogle.localdomain> <1081740243.14476.11.camel@coogle.localdomain> <5.1.0.14.2.20040412134325.039c7758@127.0.0.1> <1101B839-8C98-11D8-BB64-000A95E073A0@php.net> <26E7D27E-8C99-11D8-8792-000393B2B3C0@omniti.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <DD7A9EB4-8CA2-11D8-932F-000A95E073A0@php.net>
Content-Transfer-Encoding: 7bit
Cc: John Coggeshall <john@coggeshall.org>,
	Derick Rethans <derick@php.net>, Andi Gutmans <andi@zend.com>,
	PHP Internals <internals@lists.php.net>
Date: Mon, 12 Apr 2004 10:00:13 -0700
To: George Schlossnagle <george@omniti.com>
Subject: Re: [PHP-DEV] Exceptions and Errors
From: sterling@php.net (Sterling Hughes)


On Apr 12, 2004, at 8:50 AM, George Schlossnagle wrote:

>
> On Apr 12, 2004, at 11:42 AM, Sterling Hughes wrote:
>>
>> I like OO (*), and I think warnings (non-fatal errors) as exceptions 
>> are a stupid idea.  Does that count? ;-)
>>
>> Exceptions in languages like Java are used explicitly to catch fatal 
>> errors, not to catch basic errors.
>
> If 'languages like Java' means languages designed for OO, then this is 
> not true.  Python throws exceptions for almost everything (KeyError, 
> for example). Even Java throws exceptions (java.sql.Exception) for 
> things like failed database connections which are warnings in PHP.
>

Languages like Java doesn't mean languages designed for OO, but 
languages closely adhering to the OO model that PHP uses, Java being 
the language that can most easily be called the parent of our current 
model - although I do keep Python in this context even after your 
KeyError example.  The triviality of an exception doesn't make 
exceptions themselves less severe.  Whether or not a KeyError is 
warranted as an E_ERROR, doesn't in fact change that a KeyError will 
bump you firmly out of your control flow branch, and make you handle an 
error condition.  In PHP, E_WARNINGs may be misused (that's a 
discussion for another time, i think); but the fact remains, they do 
not end your current control flow branch.  Changing E_WARNING's to 
errors catchable by try{}catch{} will not only break BC, but will not 
make sense for a large number of warnings currently thrown for PHP and 
lead to the same inconsistencies.

John has gone ahead and committed a perfect example of where exceptions 
just mess things up.  In the tidy extension if you try and set an 
unknown configuration option it throws an exception.  This is not by 
any stretch of the imagination an unrecoverable error, but rather a 
simple failure.  Yet, if you use tidy in a script, and it is not within 
a try {} catch {} block your script execution will be terminated 
because the configuration option could not be resolved.  This is much 
less than desirable and probably confusing for someone who doesn't 
understand what an exception or why he should care.

You might argue that python or java would throw an exception in this 
case.  For the majority of the java standard library and python code i 
have found this the opposite, however, even conceding that, PHP should 
never do this.  We have the concept of warnings, in our world an error 
of this type does *not* terminate script execution.  There are even 
less severe usages of warnings throughout the PHP source code, and 
there is no reason to convert them to exceptions.  And if you don't, 
you still have the same inconsistencies.

Java and Python both use a mix of philosophies, and indeed there is no 
complete consensus.  However, in my experience and the books that I've 
read on the subject, the general thought is:

a) throw specific exceptions, not just a "tidy_exception."  PHP would 
need to add a library of built-in exceptions to make this even remotely 
useful.  this is not feasible to do at RC1.66666667

b) don't throw exceptions except when truly exceptional.  a function 
failing is usually not an exception, but rather signified by failure. 
The exception to this is when using constructors that contain logic 
(considered bad practice by many btw), and overloading.  In these cases 
exceptions are used in leu of a better solution.  This brings us back 
to KeyError - KeyError is only thrown when overloading is used:

names = ["barney", "fred", "wilma"]
print names["betty"] # throws an exception
print names.get("betty") # returns None

Most of the exceptions i've found when using both these languages 
happen on something that maps to something more severe than a 
configuration option not being found. YMMV.

-Sterling