Re: Unicode conversion exceptions and memory leaks

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