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

Laurent Laville wrote:

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.

If i've well understood, in our case its not possible, because we test each API parameter too see if developer could send wrong data (value, type). So in the case you gave, it's impossible to be true . All interval function as (bar) will always return a good result because its parameter are probably the same as foo(), so it was already checked.

Ok if you know that during the entire lifecycle of this major version you will never use a public method inside any other method then indeed you are safe. Thats quite a brought assumption though. It for example means you can never sensibly have a convinience wrapper method that calls a common sequence of public methods. Becuase in that case you would either need to replicate all parameter checks inside the convinience method or you should have to not do any error checking. I have pondered this problem in quite detail for MDB2, hoping I could somehow magically support exceptions like PDO does. However since MDB2 method make such heavy use of internal methods it was obviously not feasible. To conclude: if you feel safe doing the above mentioned assumptions then I guess its your call to make. You are defaulting to PEAR error handling so as long as you never ever cut corners on internal error handling its all good.

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.

for the PEAR::isError() we can make something to avoid includes PEAR.php to test results @todo for a RC2

This sounds like a cludge to me. Anyways it should be trivial to add the include of the PEAR.php for the version distributed inside PEAR. regards, Lukas