> Am 05.07.2015 um 23:45 schrieb Nikita Popov <nikita....@gmail.com>: > On Sun, Jul 5, 2015 at 10:51 PM, Nikita Popov <nikita....@gmail.com> wrote: >> On Sun, Jul 5, 2015 at 10:33 PM, Stanislav Malyshev <smalys...@gmail.com> >> wrote: >> >>> Hi! >>> >>>>>> I can see your concern here -- however this is nothing specific to >>>>>> exceptions thrown from __toString(). There is are a number of ways you >>>>>> can end up in this situation, the two most common being: >>>>> >>>>> I summarize this a bit freely as "We already have places which are hard >>>>> to understand an predict, so let's add more!" >>>>> >>>> >>>> That, or "Let's not be hypocrites". >>> >>> I don't think the position of "let's not add more unpredictable behavior >>> to the engine" is adequately described as "hypocrite". We know there are >>> interruption problems and such in the engine, we know some of them are >>> hard to fix. However, adding a different class of those doesn't make it >>> better in any way. If we find a solution that allows us to not introduce >>> new unpredictable behaviors - I'm all for it, it's great. Maybe the code >>> that allows to throw exceptions the same way we do with errors, maybe >>> some way to not get unpredictable results on conversions. But we can't >>> just ignore it because there are other problems in the engine too. >> >> >> Sorry, I just find it somewhat weird that we consider some of the >> exceptions generated as the result of __toString calls to be okay (error >> handler exceptions), while others are considered to be too dangerous to >> allow (direct exceptions). >> >> But maybe I just approached this from the wrong direction. Instead of >> allowing exceptions in __toString in combination with some hardening of the >> VM, maybe we should just convert the recoverable fatal errors __toString >> currently throws to actual fatal errors? Not a huge fan of doing that, but >> at least it's consistent. >> > > I just realized that this wouldn't quite cut it, because our object to > integer and object to float conversions currently throw notices, which can > be converted to exceptions and to-int conversions at least are all over the > place. Presumably it's not acceptable to change these notices to fatal > errors. > > Furthermore the array-to-string conversion also throws a notice since 5.4, > which can also result in an exception. While we approved an RFC (not > implemented) to make this a recoverable error, I suspect making this a real > fatal error will not be met with much enthusiasm. > > Nikita
We have a rather messy behavior here… Failed object -> string is an error (if not caused by exception: E_RECOVERABLE) Everything else a notice with return value 1? So, how are we handling code which likes to convert recoverables into exceptions? That's not that rare. Sure… we're passing the empty string forward? and the code calling zval_get_string() is continued… We already *have* that behavior. Can we please add consistency here and always return an empty string to be passed forward? Or… as Nikita proposed always do a real fatal (E_ERROR). In case we display E_ERROR, I'd like to ensure that the exception is displayed properly in any case. I totally am on Nikitas side that either everything should be exception or fatal. Recoverable isn't doing any good here. But I strongly feel for allowing exceptions here. P.s.: Ideally, we'd also change the object -> int/float cases to behave consistently with the strings. But that's maybe now off-scope for 7.0… Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
