Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9085
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <3D578972-8CB0-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> <DD7A9EB4-8CA2-11D8-932F-000A95E073A0@php.net> <12C1A2DA-8CA6-11D8-8792-000393B2B3C0@omniti.com> <493538C4-8CAD-11D8-932F-000A95E073A0@php.net> <3D578972-8CB0-11D8-8792-000393B2B3C0@omniti.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <82120D62-8CB4-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 12:06:31 -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 11:35 AM, George Schlossnagle wrote:

>
> 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.
>

Could be a version mismatch with tidy, and a newer library.  They 
develop there code, the option exists, and then someone with an older 
version of the library doesn't have that.  Whether or not i have 4 
spaces or 2 in my output is rather inconsequential.  Now you deploy 
somewhere else and this explodes somewhere within a function and bumps 
the script out of a critical execution context and refuses to work.

>>>> 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 did.  fast-forward to the end of this message, that's exactly the 
point john brought up.


>>> 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've probably written a considerably large amount of python and I 
haven't run into this rampant exception problem you talk about.  Could 
also be the reason why I like Python more than you... ;)  It makes 
sense that overloads would cause exceptions, as it does with type 
casting exceptions - remember, python is a strongly typed language, 
that type schiznizzle is important to them.

>>
>> 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.
>

I would probably agree with you on E_ERRORs.

>> 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.
>
>

Ok, then we disagree.  I think its entirely inconsistent because the 
two systems don't map to each other, and you get plenty of cases where 
the two simply don't map.  John is talking about *all* E_WARNINGs in OO 
code, and in the procedural variants, sending E_WARNINGs.  The scope of 
E_WARNING is not in my opinion the same scope as an exception in any 
language, and we may just have to agree to disagree.

-sterling