Re: Re: [sqlite] PHP5 && SQLite3

Probably covered by your "engine" point: please get __toString() to work properly with string concatenation and casting :) Thanks, Jevon ----- Original Message ----- From: "Andi Gutmans" <andi@zend.com> To: "Greg Beaver" <cellog@php.net> Cc: "internals" <internals@lists.php.net> Sent: Friday, October 22, 2004 5:55 AM Subject: Re: [PHP-DEV] Re: [sqlite] PHP5 && SQLite3 > I think this is something which belongs to user-land. I don't see a reason > not to implement it in that way. > > Andi > > At 11:04 AM 10/21/2004 -0400, Greg Beaver wrote: > >f) if at all possible, It would be very good if the exception signature > >could be modified to accept another exception object as a third > >parameter. Why? > > > >try { > > // blah > >} catch (SubException $e) { > > throw new ParentException('message', CODE, $e); > >} > >..... > >class ParentException extends Exception > >{ > > function __toString() > > { > > $current = parent::__toString(); > > if ($arr = $this->getCauses()) { > > $current .= "\nThis exception caused by:\n" > > foreach ($arr as $e) { > > $current .= $e->__toString(); > > } > > } > > return $current; > > } > >} > > > >This will allow chaining of exceptions, as they can be designed to do > >already, but in a simple, standardized way. It would not need to affect > >uncaught exceptions, but __toString() could take advantage of getCauses() > >to spit out this information. > > > >see pear-core/PEAR/Exception.php for userland example. I'd like to remove > >as much logic from this class as humanly possible, and concentrate its > >efforts on display of information only. > > > >If this sounds like a worthy effort, should I open a feature request? > > > >Thanks, > >Greg > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >