Re: Re: cvs:

Alexey Borzov wrote:

Hi, Lukas Smith wrote:

There are 2 obvious problems: 1) Useless bloat. People complain now (rightfully) about PEAR_Error, why make them complain about PEAR's wrapper around 'throw'?

thats a valid convern of course. personally I find this bloat obsession overrated, especially since generic OO libs are not for speed freaks anyways. however with our old system one of the main concerns beyond LOC was that PEAR::isError() is expensive. This custom throw wrapper would only be called in case of an exception, which by definition shouldnt be the common case or we are talking about trigger happy libaries. but still its a valid concern.

The most valid concern is that people wishing to integrate PEAR libraries into their code will *have* to use new convoluted exception wrapping mechanism instead of 'throw'.

Why would they have to use the PEAR wrapping mechanism? Only if they want the same level of control.

If B::doBar() fails, then an exception is thrown and catch {} block is being run. If you switch off exceptions, then execution continues RIGHT AFTER this line, not in catch {} block. Therefore, this situation needs to be handled also, or you'll not get any meaningful result from A::doFoo(). Which means, more useless error handling, which was supposed to be deprecated by exceptions.

Contrary to popular believe applications can still produce output even if something went wrong. Again this is however probably not desireable once you have final code, but during refactoring and more importantly during prototyping this is very much desireable. During that stage I often (intentionally) break parts of the code as I am changing things around for my client, sometimes even just briefly during a meeting. There I dont have the time to deal with exceptions and again a giant try/catch block will only mean I dont see anything at all. But during prototyping I dont need 100% correctness of my application. All that I need is that enough of the application sort of works so that my client knows where things are heading. Claiming that exceptions will allow you to produce bug free prototypes in the same amount of time in which you selectively ignore errors is probably either a radically better programmer than I am or "exceptionally" optimistic (pun intended).

Sorry, Lukas, you did *not* address my concern. I was *not* talking about *your* application, you are a genious programmer and can always silence errors instead of handling them.

Uhm I temporarily (preferably selectively) disable error handling during refactoring and prototyping. I log all errors in my final code and I much rather display "uncaught exception" than showing an undefined state in the final installation. Just to make it clear.

I was talking about several levels of packages using packages. Here is a more real-life example (assuming that DB class throws exceptions): class A { function fetchStuff($dsn, $stuffParams) {

    try {
      $dbh = DB::connect($dsn);
      $res = $dbh->query($this->buildReallyComplexQuery($stuffParams));
      ...
    } catch (DB_Exception $e) {
      ...
    }

} } Let's imagine that DB::connect() fails. 1) If exceptions are "on", the execution continues in 'catch' block. 2) If exceptions are "off" your script dies with "Call to a member function on a non object". To prevent this, the author of class A will *have* to add checks after DB::connect() in complement to exception handling. Which sort of defeats the whole purpose of using exceptions.

Of course disabling Exceptions will not magically make all other fatal errors disappear. However I can attest to the fact that my development style works today and seems to me quite feasible. Of course in most cases when I do queries I use those getRow() (in MDB queryRow()) style methods, since usually my result sets are small enough that I can afford fetching all results at once. So while there is of course the possibility that disabling Exceptions will just delay the fatal error thats a reality I am faced today already. But today I can set a global callback to either log or die if a PEAR Error occurs. I can even selectively disable certain PEAR Errors (allthough the mechanism is a bit lacking today as it works with the Error codes which never defined a standard for in PEAR). So in summary the bloat you talk about here is a real concern. However I feel its not that much of an issue since LOC is really no biggy due to todays proliferation of byte code caches and since the code is only called if a potentially exceptional state is reached. I also feel that the flexibility gained is quite significant and makes refactoring and prototyping alot easier (or more specifically it retains the old ease of PHP4 times which I assume we have all come to love) while giving us the power of exceptions to make our code much more robust. So please understand that I am not argueing against exceptions. I very much see their value. However I also appreciate the fact that currently I have the power over what I want to do with all but fatal errors. regards Lukas