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. Nikita
