Re: type hinting throwing a fatal error

From: Date: Wed, 24 Aug 2005 14:13:32 +0000
Subject: Re: type hinting throwing a fatal error
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19  Groups: php.internals 
Request: Send a blank email to internals+get-18350@lists.php.net to get a copy of this message
> > Replacing the meaning of E_ERROR is elegant, but it does create a > > problem of cross-version compatibility of extensions (at the source > > code level). If you want to raise an error that terminates execution, > > you'll have to do it in two different ways - that's quite annoying. > > While I think there are a lot of situations where E_ERROR is an > > overkill, there are tons of situations where it isn't, so this is an > > issue. > > As this is only for PHP 6, I dont see a real reason as if those > extensions get updated for Unicode, things like returning ERRORs should > be revised anyway. (In any case, people *should* go through their > extension and check whether they still "conform" to our error > guidelines). If there's the capability to run PHP 6 without Unicode support, surely there's no reason for extensions to lose back compatability when they're updated...? > > Given that, I think we should go with the introduction of a new error > > level, E_RECOVERABLE_ERROR, and keep E_ERROR with its existing > > meaning. > > I can change that, but IMO it's less elegant. What do others think? > If it counts for anything, I'm with Zeev over this one. I think version compatibility's likely to become an issue in unexpected ways, and also the meaning of E_USER_ERROR is less intuitive because it wouldn't behave in a similar way to E_ERROR any more. E_RECOVERABLE_ERROR's too long though - what's wrong with E_RECOVERABLE? - Steph

« previous php.internals (#18350) next »