On Mon, 2004-04-12 at 13:00, Sterling Hughes wrote:
> 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.
There is no BC break here. We are talking about specifically new
extensions written against ZE2 which have error conditions that should
be recoverable -- and *only* in the object context. Since most of PHP
does not provide a object context, there is no expectation that they
should be modified for exceptions.
> 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 have pulled one edge case out of an entire API, and the problem here
is probably that you shouldn't complain about setting an invalid
configuration option at all -- perhaps as a E_NOTICE. Furthermore, this
exception will only occur if you use $a = new tidy() instead of $a =
tidy_parse_file().
> 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.
Again, we are talking about a very specific situation (PHP 5 extensions
written using a dual-syntax model).Things in the PHP 4 branch are not an
issue here, there is no expectation that such things would be changed.
> 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
Agreed. You can't do this in the time allowed. However, you can make
things throw tidy_exception and then in PHP 5.1 throw
tidySomeOtherMoreSpecificException which extends tidy_exception.
> 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:
If you're argument is that there should be some sort of consistency on
when an error is really an exception, I can't agree more.. However, that
it itself is an admission that there is a place for Exceptions in
internal PHP 5 OO which is not being addressed.
> 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.
Its a two-line change that I'm willing to make -- I'm more concerned
about the other extensions which are not using exceptions at all,
especially when they are warranted.
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbook http://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
