Re: Re: PEAR_Warning proof of concept

From: Date: Mon, 12 Jul 2004 18:29:02 +0000
Subject: Re: Re: PEAR_Warning proof of concept
References: 1 2 3 4 5 6 7 8 9 10 11 12 13  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-31952@lists.php.net to get a copy of this message
On Mon, 12 Jul 2004 13:21:17 -0400, Hans L <hans@velum.net> wrote: > Sergio Carvalho wrote: > > I'm definitely against PEAR libraries silencing errors by default, but I > > don't mind providing that feature to end-users. Not all PHP developers > > can be PEAR developers, but all PHP developers should be PEAR users. > > Well, I just don't like the unconformity of it. New PHP5 libs in PEAR > are gonna have to be re-designed anyway (even just to justify new > versions). I would say that it's a good opportunity to require good design. > > Frankly, I've never heard this argument before either. I think Lukas is > in the minority if he disables error handling while building even > prototype applications. I certainly don't think the demand is great > enough to implement such a low-level requirement for the rest of us > writing code. That's basically how I see it. > > Even prototype applications should follow basic design principles and > silencing errors using catch() should be very easy to do. I say that > unless there is overwhelming popular support for this & some real > examples that aren't just bad design, then it's too great a price > (non-conformance w/ other PHP5 code). Of course my .02; I just feel > strongly about application design & feel strongly about PEAR being a > PHP5 team player rather than inventing its own proprietary exception > system when PHP5 has it built-in now. > 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. 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. 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. -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--

« previous php.pear.dev (#31952) next »