Re: PEAR::DB, backends and assertExtension

Markus Fischer wrote: > > On Sun, Oct 14, 2001 at 05:43:23PM +0200, Tomas V.V.Cox wrote : > > > > DB::assertExtension, instead we need a common assertExtension method > > > > (for example in PEAR.php). > > > > > > Thats ok. There's nothing from my view against moving > > > DB::assertExtension to PEAR::assertExtension. But do _not_ change > > > its behaviour. > > > > > > What is a library of use when you can't recover gracefully from > > > errors because it just dies? > > > > > > > One thing for me is a run-time error and other thing is that the > > software dependencies aren't covered so your system doesn't meet the > > minimal requirements for using the class. > > Ok, but you are aware that you can PHP use also for other things. > Beside using if for dynamix webcontent I also use it for client > side desktop applications (ok, short php-gtk ;). This would mean, > although the library has the code to _check_ for it and return it > gracefully it doesn't make use of it and instead just dies away. > That would render its usability useless in the first place if > don't check it on the client myself and therefore double the > code. > > I think people should always be aware that PHP has been started > out as a web language but is used in many other placed to. > > Don't get me wrong, I know you contributed much and you certainly > know what you do. But I think for the reasons I have its not a > good idea to just let library code die . > > I'ld like to hear what others think about this. > > In general, and this has nothing to do with me using php-gtk > also, it is always bad thing [tm] to let library code just die > away. IMHO it would be the same as letting PHP segfault away > because of invalid data or something. IMHO if errors can be handled gracefully, they should be. Dying is for the application. - Stig