Proposal to refactor exceptions in ZF2

[Sascha-Oliver Prolic]

Hi Matthew,
Hi all,

I have a question / proposal about the current exceptions practice in zf2.

current state is (example from Zend\Search\Lucene):

1) Zend\Search\Lucene\Exception\InvalidArgumentException.php

namespace Zend\Search\Lucene\Exception;

class InvalidArgumentException
    extends \InvalidArgumentException
    implements \Zend\Search\Lucene\Exception
{}

2) Zend\Search\Lucene\Document\Exception\InvalidArgumentException.php

namespace Zend\Search\Lucene\Document\Exception;

class InvalidArgumentException
    extends \InvalidArgumentException
    implements \Zend\Search\Lucene\Document\Exception
{}

My proposal would be to refactor the latter to the following:

Zend\Search\Lucene\Document\Exception\InvalidArgumentException.php

namespace Zend\Search\Lucene\Document\Exception;

use Zend\Search\Lucene\Exception\InvalidArgumentException as
LuceneInvalidArgumentException;

class InvalidArgumentException
    extends LuceneInvalidArgumentException
    implements \Zend\Search\Lucene\Document\Exception
{}

One may say, that this has not much extra benefits, but this way I am
free to completly ignore subcomponent exceptions in userland code. I
know that I can still catch the exceptions by (in this case)
Zend\Search\Lucene\Exceptipon (or
Zend\Search\Lucene\Exception\ExceptionInterface, after the renaming of
all interfaces), but the way i showed above gives some extra stuff.

I know that the exceptions milestone is declared as done (and i have
done a lot of work on this), so I step up to care about this
refactoring for the whole framework, if my proposal gets accepted.

Best Regards

Sascha-Oliver Prolic

[weierophinney]

-- Sascha-Oliver Prolic <[hidden email]> wrote
(on Thursday, 26 April 2012, 01:50 PM +0200):

> I have a question / proposal about the current exceptions practice in zf2.
>
> current state is (example from Zend\Search\Lucene):
>
> 1) Zend\Search\Lucene\Exception\InvalidArgumentException.php
>
> namespace Zend\Search\Lucene\Exception;
>
> class InvalidArgumentException
>     extends \InvalidArgumentException
>     implements \Zend\Search\Lucene\Exception
> {}
>
> 2) Zend\Search\Lucene\Document\Exception\InvalidArgumentException.php
>
> namespace Zend\Search\Lucene\Document\Exception;
>
> class InvalidArgumentException
>     extends \InvalidArgumentException
>     implements \Zend\Search\Lucene\Document\Exception
> {}
>
> My proposal would be to refactor the latter to the following:
>
> Zend\Search\Lucene\Document\Exception\InvalidArgumentException.php
>
> namespace Zend\Search\Lucene\Document\Exception;
>
> use Zend\Search\Lucene\Exception\InvalidArgumentException as
> LuceneInvalidArgumentException;
>
> class InvalidArgumentException
>     extends LuceneInvalidArgumentException
>     implements \Zend\Search\Lucene\Document\Exception
> {}
>
> One may say, that this has not much extra benefits, but this way I am
> free to completly ignore subcomponent exceptions in userland code. I
> know that I can still catch the exceptions by (in this case)
> Zend\Search\Lucene\Exceptipon (or
> Zend\Search\Lucene\Exception\ExceptionInterface, after the renaming of
> all interfaces), but the way i showed above gives some extra stuff.
>
> I know that the exceptions milestone is declared as done (and i have
> done a lot of work on this), so I step up to care about this
> refactoring for the whole framework, if my proposal gets accepted.

Just to clarify: you're suggesting that exceptions in subcomponents
should extend the exception classes from the base component.

This seems reasonable.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[Sascha-Oliver Prolic]

Am 26. April 2012 16:15 schrieb Matthew Weier O'Phinney <[hidden email]>:

> -- Sascha-Oliver Prolic <[hidden email]> wrote
> (on Thursday, 26 April 2012, 01:50 PM +0200):
>> I have a question / proposal about the current exceptions practice in zf2.
>>
>> current state is (example from Zend\Search\Lucene):
>>
>> 1) Zend\Search\Lucene\Exception\InvalidArgumentException.php
>>
>> namespace Zend\Search\Lucene\Exception;
>>
>> class InvalidArgumentException
>>     extends \InvalidArgumentException
>>     implements \Zend\Search\Lucene\Exception
>> {}
>>
>> 2) Zend\Search\Lucene\Document\Exception\InvalidArgumentException.php
>>
>> namespace Zend\Search\Lucene\Document\Exception;
>>
>> class InvalidArgumentException
>>     extends \InvalidArgumentException
>>     implements \Zend\Search\Lucene\Document\Exception
>> {}
>>
>> My proposal would be to refactor the latter to the following:
>>
>> Zend\Search\Lucene\Document\Exception\InvalidArgumentException.php
>>
>> namespace Zend\Search\Lucene\Document\Exception;
>>
>> use Zend\Search\Lucene\Exception\InvalidArgumentException as
>> LuceneInvalidArgumentException;
>>
>> class InvalidArgumentException
>>     extends LuceneInvalidArgumentException
>>     implements \Zend\Search\Lucene\Document\Exception
>> {}
>>
>> One may say, that this has not much extra benefits, but this way I am
>> free to completly ignore subcomponent exceptions in userland code. I
>> know that I can still catch the exceptions by (in this case)
>> Zend\Search\Lucene\Exceptipon (or
>> Zend\Search\Lucene\Exception\ExceptionInterface, after the renaming of
>> all interfaces), but the way i showed above gives some extra stuff.
>>
>> I know that the exceptions milestone is declared as done (and i have
>> done a lot of work on this), so I step up to care about this
>> refactoring for the whole framework, if my proposal gets accepted.
>
> Just to clarify: you're suggesting that exceptions in subcomponents
> should extend the exception classes from the base component.
>
> This seems reasonable.
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Exactly! Should I take this over?
--
Sascha-Oliver Prolic

[weierophinney]

-- Sascha-Oliver Prolic <[hidden email]> wrote
(on Thursday, 26 April 2012, 04:21 PM +0200):
> Am 26. April 2012 16:15 schrieb Matthew Weier O'Phinney <[hidden email]>:
> > Just to clarify: you're suggesting that exceptions in subcomponents
> > should extend the exception classes from the base component.
> >
> > This seems reasonable.
> Exactly! Should I take this over?

Go for it. :)

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[Ben Scholzen 'DASPRiD']

Am 26.04.2012 16:25, schrieb Matthew Weier O'Phinney:

> -- Sascha-Oliver Prolic <[hidden email]> wrote
> (on Thursday, 26 April 2012, 04:21 PM +0200):
>> Am 26. April 2012 16:15 schrieb Matthew Weier O'Phinney
>> <[hidden email]>:
>> > Just to clarify: you're suggesting that exceptions in
>> subcomponents
>> > should extend the exception classes from the base component.
>> >
>> > This seems reasonable.
>> Exactly! Should I take this over?
>
> Go for it. :)

What about sub-component exceptions where there is no fitting exception
in the component itself? Actually in the lucene case, there should IMHO
be only one exception namespace Zend\Search\Lucene\Exception, and all
sub-components (it doesn't actually has real sub-components) should use
that one.

[ralphschindler]

> Zend\Search\Lucene\Exceptipon (or
> Zend\Search\Lucene\Exception\ExceptionInterface, after the renaming of

I see a lot of this going on right now: ExceptionInterface.

This was NOT part of the interface renaming proposal.  Exception marker
interfaces should not be suffixed with 'Interface'.  What is the status
of this framework wide?  Did we discuss the carte blanche application of
the Interface naming to exceptions?  I don't recall it.

I realize we want hard and fast rules for coding standards, ... and I
realized it's becoming progressively harder to educate and get up to
speed new contributors and ensure everyone is on the same page at all
times, but my RFC did not address exceptions as they are a special case.

-ralph

[xoops]

I always prefer the native SPL Exception's

On Tue, May 15, 2012 at 7:00 AM, Ralph Schindler <[hidden email]> wrote:

Zend\Search\Lucene\Exceptipon (or
Zend\Search\Lucene\Exception\ExceptionInterface, after the renaming of

I see a lot of this going on right now: ExceptionInterface.

This was NOT part of the interface renaming proposal.  Exception marker interfaces should not be suffixed with 'Interface'.  What is the status of this framework wide?  Did we discuss the carte blanche application of the Interface naming to exceptions?  I don't recall it.

I realize we want hard and fast rules for coding standards, ... and I realized it's becoming progressively harder to educate and get up to speed new contributors and ensure everyone is on the same page at all times, but my RFC did not address exceptions as they are a special case.

-ralph

--

Taiwen Jiang (aka D.J.)

Build Xoops Engine

http://www.xoopsengine.org

web and mobile application platform

CTO for EEFOCUS.com

Leading social platform for electronics professionals

[ralphschindler]

Our exceptions always extend SPL (native) Exceptions in one way or
another.  In other words, you can always catch \Exception or
\InvalidArgumentException if you need to.

The problem I am pointing out is that with this renaming an moving of
the Exception interface, you can no longer simply catch the marker
interface for the whole component:

   } catch (\Zend\Db\Exception $e) {

Where you're catching any exception that what thrown from Zend\Db code,
but now it would have to be written:

   } catch (\Zend\Db\Exception\ExceptionInterface $e) {

The current change removes the all usefulness that was once there where
one could simply "try to catch the base exception type for a component/
component-namepace".

-ralph

On 5/14/12 8:00 PM, D. J. wrote:

> I always prefer the native SPL Exception's
>
> On Tue, May 15, 2012 at 7:00 AM, Ralph Schindler
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>         Zend\Search\Lucene\Exceptipon (or
>         Zend\Search\Lucene\Exception\__ExceptionInterface, after the
>         renaming of
>
>
>     I see a lot of this going on right now: ExceptionInterface.
>
>     This was NOT part of the interface renaming proposal.  Exception
>     marker interfaces should not be suffixed with 'Interface'.  What is
>     the status of this framework wide?  Did we discuss the carte blanche
>     application of the Interface naming to exceptions?  I don't recall it.
>
>     I realize we want hard and fast rules for coding standards, ... and
>     I realized it's becoming progressively harder to educate and get up
>     to speed new contributors and ensure everyone is on the same page at
>     all times, but my RFC did not address exceptions as they are a
>     special case.
>
>     -ralph
>
>
>
>
>
> --
>
> Taiwen Jiang (aka D.J.)
>
> Build Xoops Engine
> http://www.xoopsengine.org
> web and mobile application platform
>
> CTO for EEFOCUS.com
> Leading social platform for electronics professionals
>
>

[Sascha-Oliver Prolic]

2012/5/15 Ralph Schindler <[hidden email]>:

> Our exceptions always extend SPL (native) Exceptions in one way or another.
>  In other words, you can always catch \Exception or
> \InvalidArgumentException if you need to.
>
> The problem I am pointing out is that with this renaming an moving of the
> Exception interface, you can no longer simply catch the marker interface for
> the whole component:
>
>  } catch (\Zend\Db\Exception $e) {
>
> Where you're catching any exception that what thrown from Zend\Db code, but
> now it would have to be written:
>
>  } catch (\Zend\Db\Exception\ExceptionInterface $e) {
>
> The current change removes the all usefulness that was once there where one
> could simply "try to catch the base exception type for a component/
> component-namepace".
>
> -ralph
>
>
> On 5/14/12 8:00 PM, D. J. wrote:
>>
>> I always prefer the native SPL Exception's
>>
>> On Tue, May 15, 2012 at 7:00 AM, Ralph Schindler
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>
>>        Zend\Search\Lucene\Exceptipon (or
>>        Zend\Search\Lucene\Exception\__ExceptionInterface, after the
>>
>>        renaming of
>>
>>
>>    I see a lot of this going on right now: ExceptionInterface.
>>
>>    This was NOT part of the interface renaming proposal.  Exception
>>    marker interfaces should not be suffixed with 'Interface'.  What is
>>    the status of this framework wide?  Did we discuss the carte blanche
>>    application of the Interface naming to exceptions?  I don't recall it.
>>
>>    I realize we want hard and fast rules for coding standards, ... and
>>    I realized it's becoming progressively harder to educate and get up
>>    to speed new contributors and ensure everyone is on the same page at
>>    all times, but my RFC did not address exceptions as they are a
>>    special case.
>>
>>    -ralph
>>
>>
>>
>>
>>
>> --
>>
>> Taiwen Jiang (aka D.J.)
>>
>> Build Xoops Engine
>> http://www.xoopsengine.org
>> web and mobile application platform
>>
>> CTO for EEFOCUS.com
>> Leading social platform for electronics professionals
>>
>>
>

Hi Ralph,

i agree with you, but this was not mentioned in the rfc to keep the
exceptions as they are.
I am ready to convert the exceptions back, if needed, but we should do
a final decision on that.

Best Regards

Sascha-Oliver Prolic

[weierophinney]

-- Ralph Schindler <[hidden email]> wrote
(on Monday, 14 May 2012, 06:00 PM -0500):

> > Zend\Search\Lucene\Exceptipon (or
> > Zend\Search\Lucene\Exception\ExceptionInterface, after the renaming of
>
> I see a lot of this going on right now: ExceptionInterface.
>
> This was NOT part of the interface renaming proposal.  Exception
> marker interfaces should not be suffixed with 'Interface'.  What is
> the status of this framework wide?  Did we discuss the carte blanche
> application of the Interface naming to exceptions?  I don't recall
> it.

Actually, we did. That was part of the decision when we discussed it
during the IRC meetings.

> I realize we want hard and fast rules for coding standards, ... and
> I realized it's becoming progressively harder to educate and get up
> to speed new contributors and ensure everyone is on the same page at
> all times, but my RFC did not address exceptions as they are a
> special case.

A few things:

 * Consistency. If interfaces are going to have an "Interface" suffix,
   all interfaces should. It's much easier if rules do not have
   exceptions, or few exceptions.
 * You can still catch the "component level" exception -- you just have
   to reference it by it's fully qualified interface name.
 * You can alias the exception interface to make it shorter:
    use Zend\Db\Exception\ExceptionInterface as DBException;

Overall, I think the renaming is good from a _consistency_ standpoint,
and that the naming issues in terms of catching exceptions are trivial
and can be addressed by aliasing.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc