Re: Re: PEAR_Warning proof of concept

Lukas Smith wrote:

Not really. The code in question might be nicely layered with thoughtful methods doing only very specific tasks. But the fact remains that calls to this external site are scattered within your business logic. It might just be that this external source used to be an internal source etc. The point I was trying to make with this example is that forcing people to do things a certain way is limiting. It is nice to have the option of forcing oneselves to a certain style, but there are moments where you really really have other things to do than refactoring your application (let alone someone elses).

Don't refactor, just build in layers from the beginning! ;) You should be able to anticipate that fetching data from remote sites might not always work.

You seem to approach error handling from the view point of unlimited time and ressources (at every stage of development/maintainance). However PHP is used often where exactly this is not the case as choice and flexibility in the solutions is until now the main selling point over other solutions.

Yes, perhaps. I certainly think error handling is essential and applications should be built from the start with error handling in mind. The problem with adding a ?::throw() method to wrap the throw() language construct is not only that it is a hack & skews your backtrace, but it also is a solution that will be incompatible with any non-PEAR PHP5 code. So as long as you just stick to using PEAR components, then sure, you can disable error handling, but as soon as you want to start working with a non-PEAR library then you have a big mess. Exceptions provide a way for PEAR to "get along" with non-PEAR code. Why kill that possibility by inventing some weird requirement that cannot be met by built-in language features. I don't see any overwhelming legitimacy or support for this feature. It can easily be avoided through layered design & it's just not worth deviating from the built-in language construct. Hans