Re: Re: PEAR_Warning proof of concept

Justin Patrin wrote:

I'm not sure why you're so against this. PEAR wouldn't be inventing its own exception system, it would be merely adding to it. We're already doing this with PEAR_Exception. Adding a wrapper for throw is not reinventing, it's adding a feature. Yes, the backtrace is one layer deeper and I agree that it skews things a bit and may be hard to handle (if you, say, programmatically check the backtrace...although I'm not sure why you would need to), but adding flexibility is a good thing.

But *why* should PEAR go out of its way to facilitate sloppy coding? I don't see it saving any time, realistically. It's ok to require applications that use PEAR core libs to use this error handling. It's part of the PHP language. I don't think that "why not?" is a reason to make a fundamental change to the way exceptions are thrown. There has to be a very good reason to justify the ugliness, the extra code, the skew of the backtrace, the break of consistency with non-PEAR code -- and I just haven't seen any even quasi-good reason for this.

You still haven't addressed the issue of people using old code. Let's say you want to use a huge PHP4 system, but you also want to use new features that are only in a PHP5 version of a package that was used in that old system. Or, perhaps, there is a bug fix only in a PHP5 version (I can easily see this happening when a dev switched their package to PHP5). You may use this package in many places in your code. Allowing demoting of some or all exceptions to warnings would greatly facilitate this. Yes, the app should be rewritten for PHP5, but it's a huge system. This takes time. Allowing someone flexibility while migrating would be nice.

Basically, I don't think that PHP5-only features should be built around PHP4 limitations. I don't think mixed applications are going to happen. I certainly wouldn't deploy a PHP4 application on PHP5.

Ok, so that example is a transitory one. Once PHP5 is used "everywhere" this shouldn't be a problem for too long (at least a few years, though...). I still think that allowing warnings and expected errors could, in theory at least, be very useful to developers.

Warnings should definitely be allowed; that's a separate mechanism. Expected errors are catch()ed errors. I don't see any problem here. In PHP5 you cannot turn off error handling accross the board, because it's a language feature. That's fine; you can't turn it off in any other language either -- and I've never wanted to in PHP. Hans