Re: Exceptions: Error Codes Vs Class Names

From: Date: Sun, 29 Aug 2004 01:17:16 +0000
Subject: Re: Exceptions: Error Codes Vs Class Names
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-33026@lists.php.net to get a copy of this message
On Sun, 29 Aug 2004 08:53:15 +0800, Alan Knowles <alan@akbkhome.com> wrote: > How important is performance on Exceptions? - they are supposed to occur > Exceptionally, not on every application run. The readabilty benefits, > and grouping that a heirachy of Classes has , I'm sure outweights the > preformance issues: > Yeah, I thought of this a while ago. However, if code recovers from errors, they can happen all of the time. Regardless, I don't think that a marginal speed increase is worth making the code harder for us, the coders, to maintain and use. Remember that programmer time is worth more than machine time in most circumstances. > Did you do any tuning on the exception code: > > throw new My_Package_Exception > > This should be faster: > static $x = new My_Package_Exception > throw $x > Why is this faster? > APC should also make the difference negligable on loading times. > > Regards > Alan > > > > > Davey wrote: > > > Hey PEARs, Greg, > > > > I am not trying to start another debate, I just want to state some facts! > > > > I have done some benchmarking with some fake code, one using a single > > class with a class constant for each type of error, and one using a > > seperate class for each type of error. > > > > I chose the rather random number of 30 errors in each case (so in the > > first there was 30 constants and the second 30 classes). > > > > I ran the random scenario that error 17 was thrown in each case, and > > caught it. > > > > My findings are this: > > > > The definition of a single class with 30 constants is about 4 times > > faster than of the 30 seperate classes, however: > > > > because with the single class we have to check the error code using: > > > > catch (errors $exception) { > > if ($exception->getCode() == exception_class::CONST) { > > echo $exception; > > } > > } > > > > as opposed to with the other method which means only the error we want > > to check for is caught: > > > > catch (error17 $exception) { > > echo $exception; > > } > > > > it turns out to be *marginally* faster. > > > > Therefore, the only issue we need to work out is, what if what we're > > "try{}ing" can throw more than one exception? i.e. we're connecting to > > a DB, running a query, checking the result - thats 3 seperate errors. > > With the single class, we have one catch block. With the seperate > > classes, we need three catch blocks, or we need a parent class. Now, > > whilst we have a default parent class (Exception) catching all of > > these (or just our own parent class) means we need to do if > > ($exception instanceof Error17) which presumably will make it slower > > (not tested that far yet). > > > > But from my initial findings, I would say that by grouping errors into > > relevant single classes (either per package, or for each large > > procedure (i.e. user login)) is the fastest and most efficient way to > > do it. > > > > This is the first point I've disagreed with you upon Greg, I hope that > > cold hard facts will persuade you (and everyone else) that perhaps > > seperate classes is not the way to go. > > > > Certainly I hope this at least shows we need more testing before > > deciding which way to go. > > > > - Davey > > > -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--

« previous php.pear.dev (#33026) next »