As you know, exceptions were designed to be user-land and not for
internal functionality. I warned about that more exceptions were
being integrated into the extensions; and I especially warned of
ideas of integrating them into language constructs such as type hints
and conversions.
I don't have a good solution for this right now, except for adding a
lot of bulk to C extensions and the core and making them overly
complicated. Anyway, I'll discuss with Dmitry and see if he has any
ideas I didn't think of.
re: this specific case. Is it really a good idea for a type
conversion to throw an exception? People won't be expecting that from
reading the code. They'd most likely only expect methods to throw exceptions...
Andi
At 03:44 PM 4/13/2006, Andrei Zmievski wrote:
If you run this code in PHP 6 right now, you will get a nice memory
leak notice.
<?php
unicode_set_error_mode(FROM_UNICODE, U_CONV_ERROR_STOP |
U_CONV_ERROR_EXCEPTION);
$u = "< \u3844 >";
try {
$s = (binary)$u;
} catch (UnicodeConversionException $e) {
}
?>
/homes/andrei/dev/php-src/Zend/zend_unicode.c(461) : Freeing
0x013FC4E4 (1 bytes), script=e.php
From what Dmitry tells me, it is impossible to fix this with the
way our exceptions are implemented currently. I trust him on this,
but at the same time I think we need to do something. The
conversions will be happening in a lot of place and being able to
catch an exception, if one results, is an important part of the
workflow. I think Dmitry proposed that we could re-write exceptions
implementation, but also said that it would be a lot of work. I
think we should seriously consider it, though.
Thoughts?
-Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
