Remove exception subnamespace?

[ivanlanin]

Do we really need to maintain our Exception subnamespace? I don't see anything special performed nor any need to use them. We can use the normal PHP Exception or SPL exceptions instead. Removing them will also reduce our dependencies.

[gabrielbull]

How does it deduce dependencies? The point is to be able to catch individual exceptions. You can still catch these with the normal catch (Exception $e) line. If you can, you should use custom exceptions, it's just a better practice. Makes it easy for unit testing too.

[ivanlanin]

Look at this code metric as an example. If use the build-in exceptions, the number of dependencies will reduce. We're still using a custom PHPMD ruleset to be able passed because PHPMD requires a max number of 13 for coupling between objects. I'm trying to find ways to achive this number so that we can passed all standard PHPMD tests.

Regarding unit testing, we can use @expectedExceptionMessage instead of relying on @expectedException.

[gabrielbull]

@expectedExceptionMessage will be a string, not a best practice. Wouldn't exceptions only be loaded if there is an actual exception anyway? Well, that my opinion, I guess we should ask others what they think. @Progi1984 @RomanSyroeshko

I used @expectedExceptionMessage in unit tests just because of a lack of appropriate exception classes. I agree with @gabrielbull, it is much better to use @expectedException with custom exception class (not general Exception). It's a real pain to unit test classes using exception messages, because when you change the message you shouldn't forget to change it in the test. I would prefer having our our custom Exception classes with messages defined in them.

[Progi1984]

I agree totally with the answer of @RomanSyroeshko. If we use build-in Exception, an user can catch a specif exception.

[ivanlanin]

Ok. Good reasoning. Thanks, guys.