On Thu, 20 Apr 2006, Markus Fischer wrote:
> 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.
But you can still do that, just throw the exception in the handler
yourself like andrei mentioned.
> 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.
But that was not the argument that Andrei was making it all here.
Besides the point you just raised there is also the following issue
which is best illustrated with an example:
http://files.derickrethans.nl/pseudoandrei
In the example with exceptions you see that the application actually
aborts large parts (the "// lots of other shit 2" after the error),
where in the error_handler case the application can just continue.
> 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.
Imperative in Andrei's text was "to continue the *conversion* or not.",
and I think it should be up the the handler whether the *application*
should continue. Illegal sequences are about the same as including a
file which has a parse error. With this handler you can handle this
situation which is mostly a problem for normal string *operations*. If
your code needs to do something more special to handle possible broken
input there are plenty of functions to do so (like checking the return
value).
> 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 ...
But that would set a bad predecent.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
