At 01:42 PM 2/8/2002 +0100, Stig S. Bakken wrote: >On Fri, 2002-02-08 at 13:38, Yasuo Ohgaki wrote: > > Andi Gutmans wrote: > > > At 09:20 PM 2/8/2002 +0900, Yasuo Ohgaki wrote: > > > > > >> Andi Gutmans wrote: > > >> > > >>>> Name space BC problem is "bad", since script may misbehave > > >>>> without proper error message where to fix. > > >>>> It's a bad BC problem since it's harder to fix/notice. > > >>>> In some cases, it seems works well while it's not. > > >>> > > >>> > > >>> The question is how often does this breakage actually happen in real > > >>> life and not theoretically on the mailing list. > > >> > > >> > > >> Then we have different priority for BC problems :( > > >> BC _with_ error is not as bad as BC _without_ error for me. > > > > > > > > > Theoretically I agree but if BC _without_ error happens very rarely then > > > I don't think it's that bad. In any case, we could always have an > > > E_MIGRATION for people migrating. > > > > > > > Great! > > I personally prefer to have E_DEBUG, E_INFO and clean up error > > level for functions. There about 2300 php_error/zend_error :) > > > > I'll happily contribute for it. > > > > E_INFO: > > Error like compatibility info (migration) > > E_DEBUG: > > Error useful for debugging script but not appropriate > > for production scripts. > > E_NOTICE > > Error that can be a bug in script but may be ingored. > > E_WARNING > > Error taht cannot be ignored. (Error must be handled) > > E_ERROR > > Fatal error. > >Good idea. E_DEBUG may be a good alternative to php_printf(). Heh.
Fine tuning errors is probably a good idea. E_PEDANTIC? Andi -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
