Re: [PEPr] -1 for RFC::Error Handling Guidelines for PHP5

Bertrand Mansion wrote:

Justin Patrin wrote:

You may want to call those parsing errors and you're welcome to, but according to the RFC they're warnings. Whatever, it's just semantics. Let's stop quibbling about what to call these things and add an way to handle multiple error codes / strings at once. To make this very simple, just instantiate (not throw) an exception for each one of these. Then pass them as an array into PEAR_Exception_Aggregate. It just has to be written. To make this even simpler, we can justmake $p2 in the constructor of PEAR_Exception allow an array of exceptions to be passed in. This should add 10 or so lines to the code, nothing comparatively.

I don't think this would be the best solution because instantiating a new exception for each warning (or multiple errors as they were called) is going to be very heavy, slow and won't bring any added-value in my opinion. An array of messages should be enough. I agree that those multiple errors might represent an interesting information for the user in order to help her to debug her code. So it would be cool to have them displayed as well in the exception report. But all they are, are informative messages, nothing more. So they should be added to the cause message (ie. not to the exception message). In this case, it might be interesting to have a PEAR_Warning class but I am not so sure. Maybe a lightweight version of PEAR_Error could do the job. All it needs is a message property and a way to access it IMO.

I disagree here - a message is not good enough. Remember, developers almost never choose informative messages. There needs to be some other way of determining what happened, or we will run into the problem I described with DOMDocument->validate(). Again, with proper usage, there shouldn't be more than 2-4 warnings or errors generated in an entire program run. Performance will not be an issue. Even in a case where 100 are generated, the performance is not going to cause even a ripple in the program flow. Far more destructive to performance are activities such as socket connections and poorly formed database queries. Greg