Re: [RfC] Services_Weather

Hi, Just to clarify: Unless your package is handling errors from another package, I don't think it should be necessary to control error handling, as there are many situations in which your package will be used: - debugging (catch and display all errors) - production (suppress or re-format error messages for users) - as part of another package (repackage errors into errors for the package in some cases) This is not a standard or even a guideline right now, but once all the dust settles on the other things (BC, subpackages), I will probably bring it up more formally so that the path of continual improvement is walked :). Maybe change the call of raiseError() to: return PEAR::raiseError($message, $code, null, null, "Services_Weather_Error", null, false); Then the constructor of PEAR_Error can use the global error handling values. As for your package, I'm excited by what it can do, and the code's quality. It might make sense to name the weather.com error codes SERVICE_WEATHER_ERROR_WCOM_* or something to distinguish from package errors programmatically, but I don't think that is a big deal. I would suggest naming checkData() Services_Weather_checkData() in buildMetarDB.php, or explicitly specifying in a comment at the top that this may cause problems if used via include() In the constructor for Services_Weather_Common, I would suggest the better way to determine the presence of Science_Astronomy is to simply iterate through the include_path, postfixing "/Science/Astronomy.php" and using good 'ol file_exists() - the overhead will be much smaller, and possibly more accurate, as there can be many PEAR installations, and the only way to determine which you're in is to know before you start by using a <replace /> value in package.xml - which is a bit too complex for this package, I think. Hope this is helpful :) Regards, Greg Marshall Roch wrote:

Alexander Wirtz wrote:

after the suggestions from last time I proposed Science_Weather, I redid the whole idea and came up with the stuff you can find at http://www.pc4p.net/pear/Services_Weather/

The API as shown in the examples looks excellent. I haven't looked over the drivers yet, but I came across the same problem that Greg mentionedto me about File_IMC: error handling should be left to the user's application. in raiseError(), you pass PEAR_ERROR_RETURN and E_USER_NOTICE to PEAR::raiseError(). Greg's method was to let the user's script decide how to handle/display the error. A more in-depth perusal to come. So far, I'm impressed. :)