Re: Re: PHP Standards and Best Practices for PHP 5.3+ Frameworks and Libraries

On Tue, May 26, 2009 at 22:25, Matthew Weier O'Phinney <matthew@zend.com> wrote: > I agree with "SHOULD provide". That said, why *wouldn't* you provide > one? It's very common practice to catch exceptions based on type, and > having a specific "type" based on the given package would only give more > options to developers. What feels like "overkill" to you? That every single package is required to have its own local Exception feels like an overhead. What if my package is tightly integrated with another one, which throws bunch of exceptions, am I then responsible to catch all those exceptions and repackage them using my own local one? What if I have deep hierarchy in my package, must every single namespace have its own exception? And on a related note; what if I have multiple exceptions.. are they all supposed to be declared in the core package namespace? And the file itself should be in the same folder as Exception.php? Won't that scatter the root package folder with useless (almost empty) files? >> > <?php >> > namespace vendor\packagename; >> > class UnexpectedValueException extends UnexpectedValueException >> > implements Exception {} >> >> I don't even know what this does it is so confusing :) are you sure >> the example doesn't contain typos? > > What exactly is confusing? The typo in the example made it really confusing. Also, "overwriting" builtin classes with your own is very confusing, there is nothing stopping people from accidentally (or intentionally) make up DomainException which extends \ErrorException.. that makes no sense as \DomainException extends \LogicException. I suppose the idea was to allow packages to throw an exception with the same name as builtin once, with added features.. I'm just afraid about the readability/debugging issues. >> > <?php >> > namespace vendor\packagename; >> [..] >> >               throw new UnexpectedValueException($method . ' is not >> >> Are you sure this is the most readable way you guys could come up with? > > Can you provide something better? There is no indication, whatsoever, that this exception is a part of the namespace, and as it has the same name as builtin one I fear developers accidentally throw InvalidArgumentException without ever declaring it in the namespace causing potential debug nightmares. Actually after reading over the resolving rules again, there is no fallback to builtin classes, so that error would hopefully be caught early. -Hannes