> Nothing to ridicule but there's a good reason that currently throw is a > statement. It has to do with us not being able to clean up properly when > we're within an expression as far as memory leaks, reference counting and > other locks are concerned. > Ah, that makes perfect sense. With exit()/die() the request is ending so any mess can be cleaned up and tossed out. With a throw, there's every liklihood that execution is going to continue.
> Theoretically your patch could be applied as it's not the worst thing > (there are other existing situations where such edge cases could be > triggered) but I think it's better to keep the current state. I'd also > have to check if there aren't actually real additional problems > (misbehaviors) that could occur. > I wouldn't doubt that there are real showstoppers hiding behind that behavior. Probably surmountable ones, but not as trivial as they first appeared when I was looking at it. > I must say that I am debating with myself on this issue as syntactically > it's nice but I'm worried of the implications. It requires some thorough > analysis. > Agreed. Syntacticly it'd be nice if throw were consistent in this regard, but it absolutely needs to be approached cautiously. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
