Re: Re: PEAR_Warning proof of concept

Hans L wrote:

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

I have mixed feelings here. For one, PHP is at heart a scripting language. Scripting features, like excellent RAD, made it the success it is today. If we can keep these features, then great! On another line, legacy code is sometimes ill-designed, and this really shows when you try to apply exceptions. Exceptions are a bliss when the design is A-grade, but can be hell on you if the code approaches spaghetti style. Think of it as a "design error amplifier". So, I'd like to require proper error handling for code submitted into PEAR, but allow code using PEAR to be able to retain old vices. The cost of not doing this is a higher learning curve for PHP5 and smaller adoption. I'm definitely against PEAR libraries silencing errors by default, but I don't mind providing that feature to end-users. Not all PHP developers can be PEAR developers, but all PHP developers should be PEAR users. Cheers, Sérgio Carvalho

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc