[3.0] Reorganize exceptions (part 1 - specialized exceptions)#3131
[3.0] Reorganize exceptions (part 1 - specialized exceptions)#3131Majkl578 wants to merge 48 commits intodoctrine:developfrom
Conversation
|
@morozov Please take a look at this, currently one extracted/removed method per commit. |
6c10ed8 to
7b5f2f8
Compare
morozov
left a comment
There was a problem hiding this comment.
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.
| if (isset($params["platform"])) { | ||
| if ( ! $params['platform'] instanceof Platforms\AbstractPlatform) { | ||
| throw DBALException::invalidPlatformType($params['platform']); | ||
| throw InvalidPlatformType::new($params['platform']); |
There was a problem hiding this comment.
Would it make sense to change the constructor signature and get rid of the exception?
| { | ||
| if (empty($identifier)) { | ||
| throw InvalidArgumentException::fromEmptyCriteria(); | ||
| throw EmptyCriteriaNotAllowed::new(); |
There was a problem hiding this comment.
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.
| @@ -937,7 +944,7 @@ public function executeCacheQuery($query, $params, $types, QueryCacheProfile $qc | |||
| { | |||
| $resultCache = $qcp->getResultCacheDriver() ?: $this->_config->getResultCacheImpl(); | |||
| if ( ! $resultCache) { | |||
There was a problem hiding this comment.
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.
Agreed.
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 |
|
A few issues with the current structure (not necessarily affected by this patch):
@Majkl578 please file one or two tiсkets for 3.0 abour cleaning up and restructuring exceptions. Besides that, it looks good! |
|
@morozov At this moment I only extracted the methods to specific classes. |
|
@Majkl578 what do you say about the Scrutinizer issues like the one in Also, please squash. |
72cddfb to
d8f1786
Compare
67bd64c to
7e5fb71
Compare
c4478a0 to
e5a586e
Compare
0a11c71 to
fa42c10
Compare
3850154 to
4fbe91a
Compare
a640b82 to
e7b6c16
Compare

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.