Add missing instanceof check

[BenMorel]

Q	A
Type	improvement
BC Break	no
Fixed issues	none

Summary

The $expectedClass variable is currently unused. It should be used for an instanceof check.

[BenMorel]

Psalm complains that the condition is redundant:

ERROR: RedundantCondition - tests/Driver/API/ExceptionConverterTest.php:54:15 - Type Doctrine\DBAL\Exception\DriverException for $dbalException is always Doctrine\DBAL\Exception\DriverException (see https://psalm.dev/122)
self::assertInstanceOf($expectedClass, $dbalException);

Should we mute Psalm on this one, or should we remove $expectedClass altogether, trusting that Psalm will always check types ahead of time?

[greg0ire]

I think if there was a possibility of returning something else, Psalm would complain, so I would remove $expectedClass.

[BenMorel]

Actually, unless I'm mistaken, there may be a problem with Psalm's analysis here:

• testConvertsException() accepts class-string<DriverException> $expectedClass
• ExceptionConverter::convert() returns DriverException

And the test is:

self::assertInstanceOf($expectedClass, $dbalException);

But the sample data passes, for example, ForeignKeyConstraintViolationException as a class-string. So while $dbalException is a DriverException, there is no guarantee that it passes the instanceof check for the subclass of DriverException.

Is this a bug in Psalm?

[greg0ire]

I think it might indeed be a bug, but I cannot reproduce it: https://psalm.dev/r/7cfea887fe (or maybe it should in fact complain here)?
I reproduced the issue locally, and upgrading Psalm does not help.

UPD: my reproducer is wrong, assert is often used to coerce a type when there is uncertainty.
But even if I try if ('a' === 'a'), I don't get an error from Psalm 😅

[BenMorel]

Suprising! Not sure how to report it then. Should we suppress the Psalm error in the meantime?

[greg0ire]

Not sure how to report it then.

Well I can reproduce it locally, so a reproducer based on git clone and so on should be fine. Please report the issue, and add a link to the issue in a comment above the ignore rule you want to add.

[BenMorel]

@greg0ire Done!

[BenMorel]

sebastianbergmann/phpunit#4509 has already been merged, so the fix should land in the next PHPUnit 8.5 release. Until then, @psalm-suppress will do!

[morozov]

Thanks for taking care of this and identifying the upstream issue. I also noticed this issue while merging these changes up but never prioritized fixing it.

[morozov]

In the future, I believe it's better to identify the issue by the GitHub issue rather than a commit. Otherwise, it requires extra navigation which may not always work (e.g. if commit gets rebased or processed in some other way).

[greg0ire]

I advise this because the commit view allows to see which tags/branches it is on. I wonder if that works in case of "Rebase and merge" / "squash"

[BenMorel]

You can always navigate from issue to commit, not sure the opposite is true?

[greg0ire]

In most cases you can, I'm not sure if there are exceptions. Anyway, the PR does not contain information about branches and tags, only the commit does AFAIK

[morozov]

The exception is when a PR gets rebased (effectively, excluded from the tree). If the navigation works from the commit to the PR, it will work the other way around as well. At the same time, a PR or a commit not always exists (it can be just an issue), so from the consistency standpoint, it's better to link to issues and PRs instead of issues and commits. Additionally, issues usually contain more context, discussions, labels, etc.