Probably covered by your "engine" point: please get __toString() to work
properly with string concatenation and casting :)
Thanks,
Jevon
----- Original Message -----
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Greg Beaver" <[EMAIL PROTECTED]>
Cc: "internals" <[EMAIL PROTECTED]>
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
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
