Re: Re: cvs:

Hi Lukas & Alexey, Lukas Smith wrote:

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).

I think that the heart of the matter here is that using exceptions drastically affects the design of your code. Making it possible to disable exceptions may work for very basic applications, but any complex application that is designed to intelligently handle error conditions will likely break in horrible & difficult-to-debug ways if exceptions are disabled. As Alexey mentions, within a try-block there is an assumption that the following line of code will only execute if there is no error. Relatedly, there is an assumption that when there is an error the code in the catch() block will be executed (and that may also be substantial bits of code). Obviously when you consider that certain catch blocks can handle certain types of exceptions the situation is that much more complicated again. I think that disabling exceptions only works if you are using exceptions in a very flat, only-fatal sort of way. If the application has rich, multi-layered exception handling & recovery, then this will just create code that is *much* more confusing for package developers, users, etc. -Hans