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

-- Hannes Magnusson <hannes.magnusson@gmail.com> wrote (on Tuesday, 26 May 2009, 10:09 PM +0200): > > **Exceptions and Exception Handling** > > Each package must provide a base exception of the following name: > >   vendor\package\Exception > > Err. So every package namespace must have an Exception class/interface > called literally 'Exception'? > That feels a bit of an overkill. > How about "SHOULD provide"? 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? > > Examples: > > File - vendor/packagename/Exception.php > > <?php > > namespace vendor\packagename; > > interface Exception {} > > > > File - vendor/packagename/UnexpectedValueException.php > > <?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? * you've created the interface "vendor\packagename\Exception" * you've created the exception class "vendor\packagename\UnexpectedValueException", which: * extends the SPL exception "UnexpectedValueException" * implements "vendor\packagename\Exception" This allows you to do something like the following: try { // some code that throws an exception } catch (vendor\packagename\Exception $e) { // Caught by package exception type... // or... } catch (UnexpectedValueException $e) { // Caught by SPL exception type... // or... } catch (vendor\packagename\UnexpectedValueException $e) { // Caught by specific exception type } Bad example, as the first matches, but the point is that you have a variety of ways to catch the exception -- from specific exception types to SPL exception types to generic package exception types. (A number of frameworks provide a similar strategy already, btw.) > > Exception throwing example: > > File - vendor/packagename/Foo.php; > > <?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? Not to be blunt here, but one hallmark of the meeting we had was that if somebody didn't like something, they were challenged to provide an alternative or their rationale for their dislike. I'd like to continue with that spirit on this list. > > The goal of this meeting was to develop a set of common standards > > which PHP projects can strive towards adopting. > > Kudos. > Was there any talk about use statements? > > Many frameworks seem to reuse exceptions from other packages, thats > still valid - or does the package still have to create that "local > exception"? No -- but the strategy above is recommended, as it gives more flexibility to developers as they determine *how* they want to handle exceptions. -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/