Christopher Vogt schreef: > Hej Jochem, > >> this kind of thing belongs on php-general (and lets keep it on list >> please), if you have a serious proposal/rfc and/or one develops from a discussion >> there then likely some of the old-hats will likely recommend escalating to >> internal. > > I'm sorry I wasn't aware of this "procedure". I will start discussions > on general@ from now on. > >>> But the question remains. Are there reasons to have a Fatal error here? >> yes, it tells you your doing something impossible. > > Well yes, but this does not mean it has to terminate. It could skip it > instead. well I suppose, but then that comes down to 'you can implement a language to do pretty much whatever you want' theoretically. most likely there are BC issues, performance issues and technical limitations that dictate E_FATAL in the case. >>> For comparison: Python throws an exception in a comparable case, >>> allowing me to handle the error. >> PHP != Python. python is pure OO. php is hybrid. you have to refactor your >> code in different ways. > > Python is, just as PHP, a multi-paradigm language. Both support > procedural, OOP and even functional programming styles. fair enough, but php's engine doesn't and will not (AFAIKT from core dev team stance) throw exceptions (although some new OO extensions do and/or can), the engine triggers errors. you want it to trigger exceptions, fine. simply throw an exception if your object factory can't build the requested object. >> what this comes down to is this, python gives you exceptions free of >> charge, php asks you to implement and throw them yourself ... > > You are right. This seems to be, what it comes down too. I can't say > that I am happy with it. And I think being able to handle fatal errors, > whenever possible would be a very useful feature. > > What about E_RECOVERABLE_ERROR, couldn't calling a method on a > non-object trigger E_RECOVERABLE_ERROR, instead of E_ERROR? E_FATAL means the engine is in an unrecoverable state - they can't be handled in the php code by their very definition, whether this is strictly true in this case I don't know. E_RECOVERABLE_ERROR was introduced long after it was decided E_FATAL must/should be used in the described scenario. if you really think the behaviour could be changed without breaking BC by all means submit a patch ... if it's good and the argumentation sound the core devs may accept it, otherwise change your code to work with the implementation that exists rather than complain that php is not like <insert favorite language here>. no? > > Best regards > > Christopher > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
