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

On Thu, May 28, 2009 at 4:03 AM, Etienne Kneuss <colder@php.net> wrote: > 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? Since that's basically what Hannes said already, let me put that differently: The need to be able to classify the exceptions when you catch them seems to be an indication that something else is wrong. IMO, at the time you catch an exception, you pretty much know from where that potential exception will be thrown. If you don't, that basically means that you're catching the exception in a general context, and that an exception at that point really means you have no idea what went wrong (and even what package went wrong, sic) and hence need to classify it. Doing what is proposed here is basically to help the user to not use your packages carefully, which I consider bad, especially if the cost of doing that is the definition of dummy 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. let me rephrase that: Sure, there is no point discussing over and over decisions that has been voted on. But that rule should be relaxed a bit IMO. First of all, those decisions were voted on by a small group of people, representative or not. Additionally, people even willing to participate may not have been able to, for obvious reasons. If the point of this list is to facilitate the discussion/voting of standards, why should the first standard that this list advocates/proposes be something that this list has never been able to discuss? Makes no sense to me. - > > 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 > -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal