Re: exceptions

Lukas Smith wrote:

<snip> Ucaught exceptions are fatal. This means that you are forced to deal with any exception. It can lead to huge exception blocks where previously you could focus on handling the errors you actually care for. Yes you might claim every error should be dealt with. Reality dictates otherwise and changing this just might diminish the adavantage PHP has. With PEAR_Error you have the choice to whip up a quick prototype. Over use of execeptions prevents this as it forces you to do error handling.

I don't think that the lowest-common-denominator user should be the driving force behind PEAR decisions. Good coding practice is to catch errors -- whether checking return codes as in current PEAR or using try/catch block as (I would hope!) would be PEAR of the future. A well designed application will have few top-level entry points that need try/catch blocks. Same argument for quick prototyping: this shouldn't be a design consideration in PHP libraries. PHP really doesn't need any help in being a quick prototyping language. I honestly can't imagine building a prototype where I'd want to blindly ignore all errors, but perhaps I'm just not thinking along the same lines. (I don't think anyone would argue that warnings should be exceptions.) Yes, it does force users to do error handling. There's nothing to argue there; I think that's wonderful. (finally!) The current model makes it all too easy to lose errors if you forget to check a return value. And makes it impossible to establish code "transactions" that should fail on error.

Exceptions also enable very tricky goto style code flow handling. While some people claim its ok to use exceptions for code flow as long as they dont leak out of a defined self contained piece of code, but I strongly disagree. Any mistake in this misuse of exceptions will lead to a fatal error as the exception is likely to remain uncaught.

I would say that the code flow provided by exceptions is extremely logical, as compared to the hoops you have jump through to achieve the same effect if you do not use exceptions. An exception should never remain uncaught -- there's just no reason for that. API documentation indicates which methods throw Exceptions and it is the responsibility of the person using that method to have the necessary try/catch checking somewhere in the call stack. With PEAR_Error you have to have to either break everything into very small functions (maybe not bad anyway) so you can prematurely exit your function or you have to have elaborate if() statements to achieve what would be a no-brainer with Exceptions. You can never go back up the callstack more than one level (without excruciating return code checking and re-returning) with PEAR_Error either, giving you far less control in catching errors where they are significant.

In conclusion I see exceptions as a perfect example for previously fatal errors. However PEAR code was never supposed to hit those anyways, as long as the package is properly installed anyways.

I see that as a very tragic decision for PEAR, if indeed that is to become PEAR's policy. Reminds me of an Eddie Izzard skit (I think original was about UK in the EU) ... PEAR is not in the driver's seat of PHP development, nor is it in the passenger's seat; it's outside along the side of the road picketing against using exceptions and object inheritance.

I can see exceptions in really specific cases like "connect()" for database packages as there you are not asking "can I connect" but rather "connect and retun a handle". So an error doing the connection would be an "execeptional" state. But I wouldnt say the same about a failed query due to a syntax error and I have a hard time explaining the difference to the "connect" example.

Exception in both cases. It's an error that your code needs to deal with; it's that simple. If you are really building an application where every other call to execute() is expected to report syntax errors, then it is your job to wrap that method call w/ try/catch and ignore the exceptions. If on the other hand, you are like most people and would actually like to know when something like that happens, you will have a higher level try/catch which performs the necessary rollback steps or logs the exception message, etc. Good documentation lets users know where to expect exceptions. People designing PHP5 applications will just get in the habbit of using Exceptions, because everything else out there for PHP5 will use them. And I'll be rewriting the error handling of any PEAR package that doesn't use Exceptions (e.g. I'm about to do that for Mail_Mbox) as it's not really useful to me otherwise in a PHP5 framework. Hans