Re: Re: PEAR's Error Handling and PHP5

On 6/7/06, Lukas Smith <lsmith@php.net> wrote:

Hans L wrote: I really don't want to revive a silly debate, but can you provide some concrete examples of how using exceptions in place of PEAR_Error would actually make prototyping slower? I know you've been saying that for years, but it just doesn't make any sense to me. In fact, I would say the opposite is true in my applications. I can only assume that you simply haven't used exceptions -- but I'm willing to be wrong! Say you generate a report page. There are multiple graphs that are atleast partly generated from the same database tables. Now you want to change a single one of them that requires messing around with the table schema. Obviously this will break at least part of the other graphs. I do not want to spend a single second on those graphs however. So I do not want to start having to uncomment code, add a catch block around them. I just want to see how that single change will look inside the overall layout. Its irrelevant if the other graphs spout some error messages or simply incorrect data. The point is you have multiple independent methods, modules or whatever that interact on some level that means that you are likely to break one piece when messing with certain things in another.

I understand this point of view. Here are a few things I would add: 1) You're just as likely to have a fatal error of calling a method that does not exist on an object if you are using PEAR_Error returns in such a case, which will halt your script as well. 2) Fixing the above means adding code to check for error returns simply in order to fix this problem and allow your script to run even though it has errors/bad data. This is time you could have spent just commenting out or moving a bit of code in order to test the new thing that you wanted.

Then again I really do not care what PEAR decides. I am tired of explaining this over and over. This is consuming more time than I am willing to devote to this topic. Maybe I just do things so radically different that I am just different. But it seems obvious to me that the masses want Exceptions. So I am not going to try to stall "the obvious choice" any longer. I will decide if I am willing to use an exception enabled package or not when the time comes and I do not have immediate plans to write a new package anyways.

But I guess this is all a lost cause. We could go the way that Pierre has mentioned and simply let people use what they want (or give a choice of the 2). My worry for this is twofold, as I mentioned above: 1) continued griping about the size of PEAR(_Error) (not a real problem) 2) fragmentation of error handling schemes (but I guess this can be lived with) -- Justin Patrin