* Richard Lynch <ceo@xxxxxxxxx>:
> On Thu, April 28, 2005 1:23 pm, Kelly Meeks said:
> > I can run pear from the shell, install new modules (pager,
> > html_quickform,...) but when ever I try using any pear code in a php
> > script with the appropriate includes/require (require_once
> > 'DB.php';) nothing in the php block of the script gets executed. No
> > error is thrown, and there is nothing in any of the server log files
> > to indicate what the problem might be.
My advice to the OP:
* Install PEAR files using the pear installer. The manual is very
detailed on (a) how to obtain PEAR and the pear installer, and (b) how
to use the pear installer.
* Check what the webserver's PHP include_path is -- i.e., toss up a page
that spits out phpinfo() and check for the include_path directive and
its value. Make sure that the PEAR library is installed somewhere in
that path, and, if not:
* If you can edit the php.ini file, add that path there
* If you can't, try and add a .htaccess file at the top of your web
root with the following:
php_value include_path '...'
where '...' is your include path
* If you can't do that, add an ini_set() call at the top of your
script (worst case scenario)
PEAR should "Just Work"(tm). A lot of work has gone into the installer
and the libraries. I've never had problems with it.
> The last time I tried to use PEAR, *ages* ago, I had a similar experience.
Things have changed in PEAR quite a lot, especially in the past year.
While I respect Richard's experience quite a bit, this is one area where
I will have to agree to disagree. My experience with PEAR has been that
it saves me an incredible amount of time, the code is rock solid, and
installation is simple.
> It turned out that PEAR DB.inc was loading and using the nifty PEAR error
> handling package, which was turning off error_reporting, over-riding my
> customer error_handler, and then completely *SWALLOWING* all error
> messages.
>
> Gee, thanks!
> [That was sarcasm]
This is no longer the case. PEAR error handling is very robust -- though
creation of PEAR_Error objects is fairly expensive... which is why they
should be used only when an actual show stopper is persent. My
understanding is that the new PEAR_ErrorStack and PEAR_Exception classes
are very streamlined and robust -- though I have yet to try them out
myself.
> After days of tracing through torterous class files and a ton of PHP
> source code, I kinda sorta found where it was allegedly loading in a
> config file that allegedly would have let me set where I wanted error
> messages to go.
>
> After changing that failed, I never tried to use PEAR again.
These days, you can simply add this to your script:
PEAR::setErrorHandling($mode, $options);
I'll often use something like:
PEAR::setErrorHandling(PEAR_ERROR_CALLBACK, 'handle_errors');
where 'handle_errors' is the name of a function that will handle PEAR
errors. Another way to do it is to make checks for errors after method
calls that could return errors:
$e = $db->query('SELECT * FROM table');
if (PEAR::isError($e)) {
echo $e->getMessage();
}
Handling PEAR errors is a snap these days.
> I had already wasted more time fighting with it than it would have taken
> to just write the code I wanted in the first place!
>
> > I've looked into phplib, but it seems dated and I've read where it looks
> > like there is or was plans to merge phplib into pear.
>
> I think PEAR grew out of (in part, to some degree) phpLIB.
It may have... it doesn't really resemble it now.
> I don't think you want to use phplib at this point.
I'll have to agree with you there.
--
Matthew Weier O'Phinney | WEBSITES:
Webmaster and IT Specialist | http://www.garden.org
National Gardening Association | http://www.kidsgardening.com
802-863-5251 x156 | http://nationalgardenmonth.org
mailto:matthew@xxxxxxxxxx | http://vermontbotanical.org
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
