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

On Tue, May 26, 2009 at 3:47 PM, Matthew Weier O'Phinney <matthew@zend.com> wrote: >> Matthew Weier O'Phinney wrote: >> > -- 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? >> >> If you change this to "SHOULD provide", then it defeats the whole >> purpose of the exception. IIRC this exception was meant to be there to >> enable code calling the package to have at least a global catch for the >> package's exception. This was specifically proposed from a functional >> point of few (being able to at least always catch the global package >> exception). But for this to work, you must enforce the exception to be >> there, else it defeats the whole purpose of this standard in the first >> place. > > I *knew* there was another argument I'd missed. Thanks for summing it up > so well, Stefan! There should be some clarification though – this is required for packages that throw exceptions. You may have a package that does not throw exceptions, for example a package that does not contain php code etc. -- Brett Bieber