Re: [Fwd: Re: [PEAR-DEV] Re: [ANNOUNCEMENT] HTML_CSS-1.0.0RC1 (beta)Released.]

Laurent Laville wrote:

Perharps you did't see examples especially those who present the error handling system and almost all details of customization. here there are (also included into latest bundle 1.0.0RC1):

I am talking that inside the HTML_CSS package could few method calls are checked for errors. I didnt no go through any real world code flow, but this just struck me as odd. function foo () { $result = $this->bar(); } now if bar() can return an error in whatever format the _user_ chooses its obvious why you can't put in any error handling. however this is a huge no no. the return value of bar() needs to be checked for an error if bar() can return an error.

To resume: 1. This error handling system, never include 'PEAR.php' (as many pear packages did), but only if there is at least one error.

Which means that the user cannot use PEAR::isError() unless he includes PEAR.php himself. The cost of including PEAR.php is more or less fixed per request. The more PEAR packages you use, the lower the overhead per package. Therefore I see this as a bad practice to not include PEAR.php, especially since the core performance issues have been resolved.

Furthermore it would be a good idea to offer a static isError() method so that people can check for HTML_CSS specific errors if they want.

As default behaviour raise a PEAR_Error, you may test with require_once 'HTML/CSS.php'; $css = new HTML_CSS(); $result = $css->setStyle('div', 'color', 5); if (PEAR::isError($result)) { // do something when an error is raised }

No the point is that if there were a HTML_CSS::isError() method users could differntiate between different PEAR errors. For example an error raised by DB may get send to the DBA, while an error in HTML_CSS might get send to the frontend designer. This is even more important if a package defines its own error codes. regards, Lukas