Re: Re: PEAR_Exception - some refactoring

From: Date: Thu, 09 Sep 2004 22:17:13 +0000
Subject: Re: Re: PEAR_Exception - some refactoring
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-33324@lists.php.net to get a copy of this message
On Sat, 2004-08-28 at 23:50, Bertrand Mansion wrote: > Davey wrote: > > >I personally would prefer if for web you output <pre>$same_as_CLI</pre> > >rather than a table, this will help when using CGI from command line > >(for testing, this is what ZDE uses), so that all the HTML isn't in the > >way. Also means lighter output on the web :) > > As I said to Greg, I will add a method that will allow you to get the output format you prefer. > At the moment, I don't see a need to add support for renderers to PEAR_Exception as user is > already able to get the full trace by calling getTrace(). > > I think I will change method getTraceAsHtml() in toHtml() > and add a new toText() method. > __toString() will call either depending on the context. Hi Bertrand, The lesson learnt from PEAR_Error is to keep things *light*. When writing much of the initial PEAR code, I was assuming that people would start using opcode caches in a bigger scale than is the case today. I think the fact that we're wrapping PHP's built-in Exception class is bad enough (I wish there was a better understanding between internals@ and pear-dev@ so it would not have been necessary, but...) IMHO <pre> is sufficient, for anything else you could have a (static?) rendering object if you want to provide anything fancy, for example: $xr = new My_Exception_Renderer; PEAR_Exception::setHtmlRenderer($xr); try { ... (btw, why not use class constants for PEAR_EXCEPTION_*?) - Stig

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