Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:22895 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52086 invoked by uid 1010); 20 Apr 2006 04:28:59 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 52071 invoked from network); 20 Apr 2006 04:28:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Apr 2006 04:28:59 -0000 X-Host-Fingerprint: 213.46.255.14 viefep14-int.chello.at Solaris 8 (1) Received: from ([213.46.255.14:15542] helo=viefep14-int.chello.at) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id DA/AB-19715-90E07444 for ; Thu, 20 Apr 2006 00:28:58 -0400 Received: from genuine ([80.108.128.16]) by viefep14-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20060420042853.LNVB4147.viefep14-int.chello.at@genuine>; Thu, 20 Apr 2006 06:28:53 +0200 Received: from laptop.home ([192.168.1.50]) by genuine with esmtpa (Exim 4.50) id 1FWQhG-0000MQ-U9; Thu, 20 Apr 2006 06:23:18 +0200 Message-ID: <44470E1C.2030009@fischer.name> Date: Thu, 20 Apr 2006 06:29:16 +0200 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrei Zmievski CC: Andi Gutmans , Dmitry Stogov , PHP Internals References: <7.0.1.0.2.20060413154916.014b1d88@zend.com> <7.0.1.0.2.20060413160149.03eb5d00@zend.com> <409317664cec60ee0d2086846f050abf@gravitonic.com> In-Reply-To: <409317664cec60ee0d2086846f050abf@gravitonic.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -27 X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "genuine", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrei Zmievski wrote: > The best Derick and I could come up with is a user-specified conversion > error handler. It would be invoked only when the converter encounters an > illegal sequence or other serious error. The existing subst, skip, etc > error modes would still apply. The error handler signature would be > something like: > > function my_handler($direction, $encoding, $string, $char_byte, > $offset) { .. } > > Where $direction is the direction of conversion (FROM_UNICODE or > TO_UNICODE), $encoding is the name of the encoding in use during the > attempted conversion, $string is the source string that converter tried > to process, $char_byte is either failed Unicode character or byte > sequence (depending on direction), and $offset is the offset of that > character/byte sequence in the source string. The user error handler > then is free to silence the warning, throw an exception (throw > UnicodeConversionException($message, $direction, $char_byte, $offset), > or do something else. I have no yet decided whether it's a good idea to > allow user handler to continue the conversion or not. I'd rather the > conversion always stopped. [...] Content analysis details: (-2.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.8 ALL_TRUSTED Did not pass through any untrusted hosts Subject: Re: [PHP-DEV] Re: Unicode conversion exceptions and memory leaks From: markus@fischer.name (Markus Fischer) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrei Zmievski wrote: > The best Derick and I could come up with is a user-specified conversion > error handler. It would be invoked only when the converter encounters an > illegal sequence or other serious error. The existing subst, skip, etc > error modes would still apply. The error handler signature would be > something like: > > function my_handler($direction, $encoding, $string, $char_byte, > $offset) { .. } > > Where $direction is the direction of conversion (FROM_UNICODE or > TO_UNICODE), $encoding is the name of the encoding in use during the > attempted conversion, $string is the source string that converter tried > to process, $char_byte is either failed Unicode character or byte > sequence (depending on direction), and $offset is the offset of that > character/byte sequence in the source string. The user error handler > then is free to silence the warning, throw an exception (throw > UnicodeConversionException($message, $direction, $char_byte, $offset), > or do something else. I have no yet decided whether it's a good idea to > allow user handler to continue the conversion or not. I'd rather the > conversion always stopped. My problem with those handlers is always that my control flow suddenly gets completely interrupted, i.e. right in the middle the handler is called and I've no information which class, object, function, file, source, line, etc. This is, at best, annoying. That is why I love those exception. I'm in control. Not PHP. Not someone else. I decide whether I want to interrupt my control flow or not. Now, I also understand the "but average joe doesn't know exception" argument and also the other one from this thread that it may be just technical too complex/not worth it. On the other side I fail to see the real advantage of the handler, especially when it's yet to be decided whether continuing will be allowed or not. That's a "horror" (comes from a saying in german, don't know if it makes sense here in english) when you develop in or with frameworks which have strict control flows and semantics on how to handle cases. Maybe I exaggerate in this case, feel free to ignore it. I mean hell, I would even love it when a failed require would throw an exception ... thanks, - - Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFERw4b1nS0RcInK9ARAj6fAKC+cJwqRAc3uWaN1nJQ25Wg+oFJSQCdHWBJ 2oHLQs3JLHf2T26ub08H4dc= =ADVn -----END PGP SIGNATURE-----