Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9083
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <12C1A2DA-8CA6-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>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-407274232
Message-ID: <493538C4-8CAD-11D8-932F-000A95E073A0@php.net>
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 11:14:49 -0700
To: George Schlossnagle <george@omniti.com>
Subject: Re: [PHP-DEV] Exceptions and Errors
From: sterling@php.net (Sterling Hughes)

--Apple-Mail-1-407274232
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


>
>> 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.

>> 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.  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.

>>
>> 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.
>

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'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."

Either i'm missing the point or we are agreeing this shouldn't be so.

-Sterling
--Apple-Mail-1-407274232--