Edit report at https://pear.php.net/bugs/bug.php?id=20173&edit=1

  ID: 20173
  Updated by: borz_off@cs.msu.su
  Reported By: bra at fsn dot hu
  Summary: It's impossible to do error checking in getPackage
-Status: Open
+Status: Bogus
  Type: Bug
  Package: PEAR
  Operating System: FreeBSD 9
  Package Version: 1.9.4
  PHP Version: 5.5.7
  Roadmap Versions:
  New Comment:

-Status: Open
+Status: Bogus
You kinda contradict your own words when giving the actual error
Call to undefined method PEAR_Error::getName() in
/usr/local/share/pear/Horde/Core/Db/Migration.php on line 91

In case of error a PEAR_Error object is returned, not an "error via a
string", so the calling code should check for that.

The patch doesn't look good either, it basically disables locking in
getPackage(). If you don't care about locking, you can call
_getPackage() instead, it is essentially public anyway.

Previous Comments:

[2014-01-09 07:35:57] bra

I've attached a patch, which fixes running Horde over NFS. I guess
locking in this path could be completely removed, I've just left it
there in case there will/would be some logging in the called functions,
and if this locking has any meaning at all.


[2014-01-09 07:31:58] bra

Added #patch bug:20173;patch:pear.patch;revision:1389252718;.


[2014-01-08 15:38:22] bra

I would like to run Horde from a read only NFS mount, but PEAR prohibits
me to do this, because it dies on locking its lock file.
Of course doing this on a read only medium (or on files, to which you
don't have permission) it doesn't seem to make any use, but I'm not sure
whether you can handle this case, or the calling application (in case:
Horde) should handle the error.
I was trying to compile a patch for Horde to check for PEAR's getPackage
error and noticed that it's somewhat impossible to do this right.
getPackage returns the error received from _lock via a string, exactly
the same way as it would return its normal output.
So currently Horde tries to call "could not acquire shared
lock"->getName(), which yields a Call to undefined method
PEAR_Error::getName() in
/usr/local/share/pear/Horde/Core/Db/Migration.php on line 91

Is this behaviour (giving back error messages in the normal return
value) expected and considered good?
This is the first time I look into PEAR's code, is this the way it
handles errors?
How the callers should check for them? Trying to make every possible
errors and track the possible error messages and via string matching?


Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
postedMar 1, '14 at 7:35p
activeMar 1, '14 at 7:35p

1 user in discussion

Borz_off: 1 post



site design / logo © 2022 Grokbase