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
