Re: Re: cvs: pear /Validate/Validate US.php

On 21 Jun 2002, Stig S. Bakken wrote: > > The frequency of errors being returned from the method calls was about > > 50%, since the keys were picked at random and didn't necessarily exist in > > the database at any given time. With 4000 attempted transactions, using > > raiseError (which occurred about 2000 times) resulted in doubling the > > execution time for the transactions as a whole. > > > > In a real-world application, this might actually amount to less time > > (hopefully fewer errors) than would be noticed, but the overhead of using > > raiseError is certainly nontrivial. > > > > > e) Using raiseError will make your life easier, if you start to migrate > > > the PEAR stuff to PHP 5 and using the try-catch-mechanism. > > > > Note: It really wasn't a big deal to convert from one to another, since I > > just used the simple $message portion of raiseError and ignored the other > > options. YMMV. > > Hi Brent, > > IMHO speed is not an important issue here, if it is you are abusing PEAR > errors. They are an emulation of exceptions, and should be used for > just that - failures that count as exceptions. This means these errors > should be rare, which means performance is not a big issue. > > PHP's error handling sucks, hard, that's why PEAR_Error exists. And it > has been designed to be forward-compatible with PHP 5. Starting to mix > the two is _not_ a good idea. Converting to try/catch may work, but why > do that when you can keep using raiseError and be PHP 4 BC? > > - Stig Alright, alright. This sounds like an intervention ;) Yes, the results from the benchmark program are artificial; it just chose a random key w/o checking if it was valid first, so errors were frequent. But, there are some other issues. In DBA_Table, there is a function to create a new table: /** * Creates a new table. Note, this closes any open table. * * @param string $tableName name of the table to create * @param array $fieldSchema field schema for the table * @param object $dba dba object to use */ function create($tableName, $fieldSchema) { // pack the fieldSchema $fieldString = $this->_packFieldSchema($fieldSchema); $r = $this->_dba->open($tableName, 'n'); $r = $r && $this->_dba->insert(DBA_TABLE_META, $fieldString); $r = $r && $this->_dba->close(); // return the result of the creation operations return $r; } Note that the results of three other functions are anded together to determine overall success. With PEAR::raiseError, would this be acceptable, or is there a better way to handle this? function create($tableName, $fieldSchema) { // pack the fieldSchema $fieldString = $this->_packFieldSchema($fieldSchema); $r = !PEAR::isError($this->_dba->open($tableName, 'n')); $r = $r && !PEAR::isError($this->_dba->insert(DBA_TABLE_META, $fieldString)); $r = $r && !PEAR::isError($this->_dba->close()); // return the result of the creation operations if (!$r) { PEAR::raiseError("DBA: Houston, wir haben ein problem"); } } Also, I have some instances where PEAR::isError() would potential be called thousands of times within a single method. Take join a join using nested loops on two tables. We iterate through two DBA drivers using this type of structure: $keyA = $tableA->firstkey(); while (!PEAR::isError($keyA)) { $valA = $tableA->fetch($keyA); $keyB = $tableB->firstkey(); while (!PEAR::isError(keyB)) { if ($valA == $tableB->fetch($keyB)) { $joinedVals[] = $valA; } $key = $tableB->nextkey(); } $key = $tableA->nextkey(); } The number of errors generated here would be size(tableB) + 1. So, an error value returned from nextkey() (as we reach the end of a list of keys) would not really be a rare event. I plan to make exceptions like this where necessary. These are my only real concerns with raiseError. I was just using trigger_error for debugging anyway, so I have no problem with using: PEAR::raiseError($message) to this end. It does work with @, right? Thanks - Brent