Re: Re: PEAR_Warning proof of concept
| From: | Justin Patrin | 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--