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

-- Hannes Magnusson <hannes.magnusson@gmail.com> wrote (on Wednesday, 27 May 2009, 09:31 AM +0200): > 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? No -- just the package level namespace requires it. And no, you don't have to catch and re-throw all exceptions. However, if you *throw* exceptions, you would throw an exception that implements or extends the package level 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? I'd argue that they are not useless. Exception typing is *very* useful, and allows for tiered exception handling strategies. > > > > <?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. Yes, the idea is to allow throwing exceptions that match the built-in SPL exceptions -- but which *also* match a package exception. The latter allows you to have different strategies when catching exceptions from specific vendors/packages (for instance, you may want to log them differently, so that you can determine the overhead of a specific package, or so that you can report issues to team members familiar with those specific packages). > > > > <?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. -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/