Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.1.0RC2

Request #4555 Return PEAR_Error instead of dying
Submitted: 2005-06-08 16:59 UTC
From: joe at joestump dot net Assigned: mfonda
Status: Closed Package: Crypt_Blowfish
PHP Version: Irrelevant OS: All
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 31 + 3 = ?

 
 [2005-06-08 16:59 UTC] joe at joestump dot net
Description: ------------ In all of the major functions you use this code: PEAR::raiseError('Plain text must be a string', 0, PEAR_ERROR_DIE); As a developer I would be expecting the function to either: a.) return true or false b.) return a PEAR_Error Certainly not for the function to kill my whole script if my encryption attempt failed. For instance, if I have a web script that takes input from the user, instead of gracefully handling this error in my own script (ie. "Your string needs to be plain text!" at the top of my form) the low level library will fatally kill my script. IMO, it should simply return a PEAR_Error on failure or true on success (or void). That way I can do this: $result = $blowfish->encrypt($notPlainText); if (PEAR::isError($result)) { // Fail gracefully } The main reason I propose this change: What if it's not really a fatal error if the encryption doesn't take place? Especially with setKey() and decrypt().

Comments

 [2005-06-08 23:29 UTC] mfonda
Ah yes, this would be good to have. In the original code (version 0.1), it had reasons to die, but the API / code has greatly changed since then, so you are right, no point in having it die now, error should be returned. I will change this and make a new release soon. :-)
 [2006-04-26 17:11 UTC] jausions (Philippe Jausions)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.