Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9078
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <DD7A9EB4-8CA2-11D8-932F-000A95E073A0@php.net>
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> <DD7A9EB4-8CA2-11D8-932F-000A95E073A0@php.net>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <12C1A2DA-8CA6-11D8-8792-000393B2B3C0@omniti.com>
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 13:23:11 -0400
To: Sterling Hughes <sterling@php.net>
Subject: Re: [PHP-DEV] Exceptions and Errors
From: george@omniti.com (George Schlossnagle)


On Apr 12, 2004, at 1:00 PM, Sterling Hughes wrote:

>
> 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.

A KeyError is an E_NOTICE in PHP.  It's so frequent in loosely typed 
languages that it is rarely severe.  Your argument is a tautology: the 
only reason it breaks control-flow in  Python is because it's defined 
to break control-flow there by means of it being an exception.


> 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.

I don't have a strong feeling about this either way, but to play devils 
advocate: You requested an option be set.  That option could not be set 
because it is impossible to set a non-existent option.  How do you know 
how someone wants to handle that error?

> 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.

The discussion was on OO code throwing exceptions.  Given that there is 
very little OO core code in php4, I don't see a widespread conversion 
happening.

>
> 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

But the beauty of OO Code is that all the tidy exceptions should derive 
from TidyException.  So life can continue as before, with no BC break.

>
> 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

You'll have a hard time defending Python as being restrained in it's 
use of exceptions for warnings.  It's a rather exception-happy langugae 
and throws exceptions for the equivalent of most PHP E_NOTICEs.

> 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.

The key point that you're missing in all this is that _you_ don't know 
what's a serious error and what's not.  Only the developer knows.  For 
instance, the python smtplib can throw any number of exceptions based 
on bad connect data or bad command responses.  Is this a 'serious' 
error?  It depends.  If sending a mail is an inconsequential part of 
the app, maybe it's just an informational warning.  It's also easy to 
imagine it being a very critical, non-recoverable error.  The severity 
of the error lies entirely in the purview of the receiver.

Nothing sums this up for me better than KeyError, which is almost never 
fatal in my applications but which constantly bites me in the ass.  
Obviously your experiences may differ, which is really the whole point.

George