Re: Re: RFC::Error Handling Guidelines for PHP5 packages

Lukas Smith wrote:

Hans L wrote:

Yes, but as Sergio mentions, you lose key features of Exceptions by adopting this solution. Sure it is *a* solution, but so is trigger_error(). Throwing & stacking are simply very different; I think that Sergio & others have illustrated that exception don't belong in stacks, because by definition they mean that program execution should not continue.

the crux of the matter might lie in the fact that alot of people see that several errors handled via PEAR_Error today should not be exceptions. Now the question is now if those are supposed to be warnings in the future or ..

Is this such a big problem? Just follow the rule in the guidelines: Can the procedure fullfil its purpose, even with the error? If positive, it is at most a warning (1). If negative, it is definitely an error, and an exception must be thrown. (1) Wether to issue a warning or not is also covered in the RFC: If the procedure performs an incomplete recovery, a warning must be issued; if the recovery is complete, it is left at the criteria of the developer.

a prime example to me would be an error inside a query. there might be syntactical errors, contraint violations, missing entities etc. right now all of these are PEAR_Error's however I would say that atleast all but the syntax errors should not become Exceptions.

If I understand the case correctly, they're all errors. The query can't be run because of them.

regards, Lukas

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc