Re: Re: PEAR_Exception - some refactoring
| From: | Stig S. Bakken | 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