Re: Re: cvs:

Alexey Borzov wrote:

Lukas Smith wrote:

If we would call our own method to throw any exception we could of course control how and when things get thrown or if at all. This would solve my big gripe that sometimes I want quick and dirty and would therefore like to disable all or selection of exceptions entirely (especially for packages written by rather exception trigger happy people).

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.

2) Let's consider the following. You use class A, which uses class B: class A {

    function doFoo()
    {
         try {
             $this->b->doBar();
             ...
         } catch (PEAR_Exception $e) {
             ...
         }
    }

} 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). regards, Lukas