Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.0] Reorganize exceptions (part 1 - specialized exceptions) #3131

Closed
wants to merge 48 commits into from

Conversation

Majkl578
Copy link
Contributor

@Majkl578 Majkl578 commented May 4, 2018

Extracting all exception factory methods to specific sub-classes, keeping the type hiearchy intact. These methods are now removed (thus BC break).
No test changes except mocks or specific factory tests.

In the next PR(s) these (now empty) exception classes will be converted to interfaces and moved to their appropriate namespaces.

First part to complete #3124.
UPGRADE update will come with the 2nd part.

@Majkl578 Majkl578 added this to the 3.0.0 milestone May 4, 2018
@Majkl578 Majkl578 self-assigned this May 4, 2018
@Majkl578 Majkl578 changed the title [WIP 3.0] Reorganize exceptions [WIP 3.0] Reorganize exceptions (part 1 - specialized exceptions) May 5, 2018
@Majkl578 Majkl578 changed the title [WIP 3.0] Reorganize exceptions (part 1 - specialized exceptions) [3.0] Reorganize exceptions (part 1 - specialized exceptions) May 12, 2018
@Majkl578 Majkl578 removed the WIP label May 12, 2018
@Majkl578 Majkl578 requested a review from morozov May 12, 2018 00:35
@Majkl578
Copy link
Contributor Author

Majkl578 commented May 12, 2018

@morozov Please take a look at this, currently one extracted/removed method per commit. Once reviewed, I'll squash them. Done already.

@Majkl578 Majkl578 force-pushed the exceptions branch 3 times, most recently from 6c10ed8 to 7b5f2f8 Compare May 12, 2018 01:49
Copy link
Member

@morozov morozov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Structure-wise, the changes look fine but therу are cases (I just commented on a few) where exceptions could be eliminated by introducing proper APIs.

Not sure how we want to proceed with that but I feel that without doing so we'll just introduce a bunch of useless classes.

Let me know what you think.

@@ -211,7 +218,7 @@ public function __construct(array $params, Driver $driver, Configuration $config

if (isset($params["platform"])) {
if ( ! $params['platform'] instanceof Platforms\AbstractPlatform) {
throw DBALException::invalidPlatformType($params['platform']);
throw InvalidPlatformType::new($params['platform']);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to change the constructor signature and get rid of the exception?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved to #3163

@@ -656,7 +663,7 @@ private function gatherConditions(array $identifiers)
public function delete($tableExpression, array $identifier, array $types = [])
{
if (empty($identifier)) {
throw InvalidArgumentException::fromEmptyCriteria();
throw EmptyCriteriaNotAllowed::new();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I'd better not have this check at all. DELETE FROM table is a valid SQL expression. Sometimes you just need to remove all records from a cache/projection table. Why should we not allow it? Probably a topic for another discussion.

Copy link
Contributor Author

@Majkl578 Majkl578 May 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved to #3164

@@ -937,7 +944,7 @@ public function executeCacheQuery($query, $params, $types, QueryCacheProfile $qc
{
$resultCache = $qcp->getResultCacheDriver() ?: $this->_config->getResultCacheImpl();
if ( ! $resultCache) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be simpler if enforced by the interfaces of $qcp and the config. E.g they both are required to have an instance of the cache driver which defaults to a null-implementation which throws exceptions from any method.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved to #3165

@Majkl578
Copy link
Contributor Author

there are cases (I just commented on a few) where exceptions could be eliminated by introducing proper APIs.

Agreed.

Not sure how we want to proceed with that

At this moment I think it's easier to keep it as is and refactor later, either as part of introducing strict types or as separate improvements. Also when an exception becomes useless during that process, it can simply be removed, it's not going to a stable release anytime soon. (And we may eventually mark them as @internal before 3.0 anyway.)
Do you want me to open issues to track those possible improvements?

@morozov
Copy link
Member

morozov commented May 12, 2018

A few issues with the current structure (not necessarily affected by this patch):

exceptions

  1. All transaction-related exceptions extend ConnectionException which probably could renamed to TransactionException.
  2. NonUniqueFieldNameException directly extending ServerException is weird.
  3. TableExistsException extending ServerException is weird too.
  4. ServerException extending DriverException
  5. More like these.

@Majkl578 please file one or two tiсkets for 3.0 abour cleaning up and restructuring exceptions. Besides that, it looks good!

@Majkl578
Copy link
Contributor Author

@morozov At this moment I only extracted the methods to specific classes.
The plan for next PR is to make them interfaces and move them around to their appropriate namespaces, also split some of them or slightly change their hiearchy as we discussed earlier. Looking forward to discussing this then. 👍

@morozov
Copy link
Member

morozov commented May 13, 2018

@Majkl578 what do you say about the Scrutinizer issues like the one in CommitFailedRollbackOnly? There are indeed two classes with the same name within the same hierarchy:

↪ find -name ConnectionException.php
./lib/Doctrine/DBAL/Exception/ConnectionException.php
./lib/Doctrine/DBAL/ConnectionException.php

Also, please squash.

@morozov morozov force-pushed the develop branch 2 times, most recently from 72cddfb to d8f1786 Compare June 6, 2018 21:46
@morozov morozov force-pushed the develop branch 3 times, most recently from 67bd64c to 7e5fb71 Compare July 2, 2018 00:52
@Majkl578 Majkl578 mentioned this pull request Jul 9, 2018
@morozov morozov force-pushed the develop branch 2 times, most recently from c4478a0 to e5a586e Compare October 7, 2018 22:01
@morozov morozov force-pushed the develop branch 2 times, most recently from 0a11c71 to fa42c10 Compare November 14, 2018 19:23
@morozov morozov force-pushed the develop branch 2 times, most recently from 3850154 to 4fbe91a Compare February 22, 2019 00:01
@morozov morozov force-pushed the develop branch 3 times, most recently from a640b82 to e7b6c16 Compare March 18, 2019 06:13
@Majkl578 Majkl578 closed this Apr 16, 2019
@Majkl578 Majkl578 deleted the exceptions branch April 16, 2019 19:48
@morozov morozov removed this from the 3.0.0 milestone May 23, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants