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

Hello, On Wed, May 27, 2009 at 2:42 PM, Matthew Weier O'Phinney <matthew@zend.com> wrote: > -- 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. > So, if I get this right: 1) any exception (Exception, SPL Exceptions, ..) used inside a package needs to be redefined as a dummy package class implementing the package-wide Exception interface, just for the sake of classifying the exceptions per package, (which seems to be a quite rare use-case in practice)? If the usage of exceptions as error handling mechanisms is the way to go, that would basically mean that you recommend bloating each package with numerous cloned exceptions classes? 2) Since a closed group of people voted on those standards, we can discuss them but they won't change? If so, that's one hell of a useless discussion then. Regards > -- > Matthew Weier O'Phinney > Project Lead            | matthew@zend.com > Zend Framework          | http://framework.zend.com/ > > -- > PHP Naming Standardization Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal