> Can you provide more details on what the error conditions are? I can > see 'non-existent static variable' and 'non-existent variable', are > there others?
Absolutely! I'll add it to the RFC later tonight, but the gist is that it would be exactly the same as if you were to call any function with something that doesn't exist. > > An exception model was considered, however, the author believes that > > it would break the concept of “using nameof wherever a string could > > be used” and wouldn't be practical for the engine to handle all of > > those cases. > > Can you put some detail in there ....I don't understand the problem, > or what you mean by it not being practical to 'handle all of those > cases' . I can do that, I agree it probably isn't as clear as it could be. One issue that was identified is that if this can be used anywhere a string/constant can be used, there may be edge cases where there is no way to handle an exception there because a try-catch isn't an expression. For example, in attributes, I'm not 100% sure the engine is set up to handle an exception being thrown while defining an attribute, nor how you would catch such an exception in a graceful way. I could be completely wrong, in which case I can add back that option. > > each one has its own merits but ultimately will > > be left up as a secondary vote: > > One of the reasons the RFC process has served PHP pretty well is that > it forces people to think through the details. > > I really don't think putting a few options up and hoping that people > choose the best one is a good way to design a language; it allows > skipping over thinking the details through. > > And yeah....this is one of the reason doing RFCs is annoying. People > are often persnickety over details. That is fair :) After some discussions with colleagues, I realized how errors are output and handled might be a contentious topic. I decided to make it a secondary vote -- and hopefully -- the discussions we're having now might inform voters on the best way to vote for how errors are handled. I don't have a personal preference (but apparently some people do), and I'd be happy with any of the solutions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
