On Mon, 12 Apr 2004, Andi Gutmans wrote: > I think the main reason for all of this disagreement, is because PHP > (pre-exception state) is not consistent with its error levels. As mentioned > here, sometimes relatively serious errors are E_WARNINGs and some less > serious errors are E_ERRORs.
I agree. One programmer's E_NOTICE is an another's E_ERROR. However, right now, all non-fatal errors are essentially trapped (or ignored) the same way. [snip discussion on the merit of exceptions] > Personally, I am not sure what my take on this is as I think most of us > agree that it's a mess and there's no perfect solution. In an ideal world, > I would prefer to write DB connection/query/disconnection code without > having to check their return values, and if an error occurs, catch that > exception and give a meaningful error message. However, it seems that > finding the right solution for PHP is going to be pretty hard. I think the other problem is that we cannot come to a general consensus on the appropriate application of exceptions. There are some developers who would prefer they're *never* used. There are others who want to use them *always*. This isn't good. :) Until we can forge some middleground on *why* we should use exceptions, it's hard to come up with a solution for how we should go about solving the messy real world issues of legacy code, different error levels for similiar problems, etc, etc. Currently, as I see it, exceptions are maybe useful for application-level problems, but not for lower level errors. Essentially, you can use exceptions to handle errors in your own components, but not in any of the underlying extensions. Maybe this is how we want people to use exceptions in PHP, but I'd prefer this to be an overt decision instead of a side-effect of inconsistent extension deployment. > Thinking out loud, it might be interesting to think of some automatic > wrapping API, which could be used in order to use exception based PHP vs. > regular PHP. However, doing this in a way which is accurate and automatic, > especially as relying on our current E_* doesn't seem to be a good option, > would be quite hard. There are no excellent options here, but maybe we can come up with one that is good enough. -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
