regarding PEAR_Error

I couldn't have said it better myself! I think the usage of PEAR_Error right now is sloppy and inconsistent. I am surely no saint, but I think I have followed the model closer than most. If you check out XML_XPath, XML_CSSML, System_Command and Net_UserAgent_Detect you will see that I put all my error codes as constants = negative error codes, then used errorMessage, isError and the full raiseError, including the level of php error (notice/warning/error). I often return the PEAR_Error to the user, but that is so like in DB they can do if (DB::isError($db = DB::connect('mysql://etc..'))) { die($db->getMessage()); } and so forth. In cases where I have to do a lot of different stuff at once without returning I have used an errorStack (well, not in those classes, but I have in a 5th class I have) which collects these errors to be used when I throw the error CLASSNAME_STACKTRACE_ERROR or something...but that is much more specific. I haven't yet used @throws, but that is a good idea. I guess I could list the potential error codes (as constant names) that could be throw. Anyway, just wanted to put my vote in. Oh, and one thing that is definitely not acceptable, I saw one developer printing the error message from the class method, which is just not acceptable and sloppy. Throwing an error DOES NOT slow down your class, because it only throws it, if there IS and error...and php is so fast at checking types and strings that it is WORTH CHECKING for errors! IMHO Dan -- ________________________________________________________________ Daniel Allen, <dan@mojavelinux.com> http://www.mojavelinux.com/ ________________________________________________________________ [Frodo]: "He deserves death." [Gandalf]: "Deserves it! I daresay he does. Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends." ________________________________________________________________