On Sun, 2015-07-05 at 23:45 +0200, Nikita Popov wrote: > 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.
I fully agree that the current situation is bad. I just don't see an improvement by this change, rather a new set of WTFs for the user. In the ideal world we can throw everywhere without issues (well, except maybe exceptions escaping from destructors in shutdown maybe ... while maybe that's not different from other uncaught exceptions) Maybe we have to restructure internal exception handling for that? Maybe we can create a plan leading there for a future version? johannes (who dreams of a complete new and unified error&exception handling, but never managed to sit down to create a good proposal ...)
signature.asc
Description: This is a digitally signed message part
