Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9084
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <493538C4-8CAD-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> <12C1A2DA-8CA6-11D8-8792-000393B2B3C0@omniti.com> <493538C4-8CAD-11D8-932F-000A95E073A0@php.net>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <3D578972-8CB0-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 14:35:57 -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 2:14 PM, Sterling Hughes wrote:

>
>>
>>> 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?
>>
>
> I assume they don't want their script to stop executing, their 
> transactions to be rolled back and a nasty error page shown :
>
> "Uncaught exception, could not set tabsize to 2 spaces"
>
> That could just be my crazy assumption though.

It is.  It's a hardocded portion of their app, and they made a mistake. 
  They may not care, but it's also possible that they do.  Assuming that 
they don't care enough to fix it seems equally crazy to me.

>>> 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.
>>
>
> No, this discussion was on having exceptions thrown instead of 
> E_WARNINGs inside OO code.

Rewind to the beginning of the discussion, the scope is not as broad as 
you claim.

> I'm pointing out that the two paradigms don't map, and in other 
> languages for many of the common errors given by E_WARNINGs (but not 
> all) simply wouldn't propagate as Exceptions.  Many cases it would, 
> but in order for this idea to work, it needs to map for the most part, 
> which it doesn't.

[snip]

>> 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.
>>
>
> I haven't noticed that, and I've written quite a bit python code.  It 
> does throw exceptions, no argument, but it depends largely on what you 
> are doing.  The above example you've given is a place where an 
> exception is not out of place (although I don't particularly like one 
> being thrown), because you are using an overload.  Different paradigm 
> than PHP arrays imho.
>
>>> 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.
>>
>
> Well, you can use get() now and be happy. :)

I could,  I could also catch my exceptions.  There are plenty of other 
exceptions (casting errors, etc) that will irk me whenever I use 
Python.

>
> I'm not saying that exceptions should never be used.  But, John 
> suggested "As a matter of consistency, I would like to suggest that 
> for those extensions which have a OO/procedural syntax that the 
> non-fatal errors
> generated by those extensions be thrown as Exceptions when called from 
> an OO syntax."

I'm undecided on whether it's advisable to throw E_WARNINGs as 
exceptions.  I think that all but engine-consistency-affecting E_ERRORs 
should be exceptions, but that's a different discussion.

> Either i'm missing the point or we are agreeing this shouldn't be so.

You were saying that not doing this was consistent with other 
languages.  I was saying that it was not.

George