- Issue created by @mondrake
- ๐ฎ๐ณIndia dineshkumarbollu
Hi @mondrake
Created patch for this issue, please review.
- First commit to issue fork.
- Merge request !7286Replace calls to ::expectError*() from Drupal\Tests\Core\Render\ElementTest โ (Open) created by quietone
- Status changed to Needs review
4 months ago 11:20am 2 April 2024 - Status changed to Needs work
4 months ago 11:27am 2 April 2024 - ๐ฎ๐ณIndia dineshkumarbollu
Hi @quietone
#6 Needs work is due to Tests Failure? - ๐ฎ๐ณIndia samit.310@gmail.com
samit.310@gmail.com โ made their first commit to this issueโs fork.
- Merge request !7322Resolve #3427177 "Replace calls to expecterror" โ (Open) created by samit.310@gmail.com
- Status changed to Needs review
4 months ago 10:08am 4 April 2024 - Status changed to Needs work
4 months ago 10:14am 4 April 2024 - ๐ฎ๐นItaly mondrake ๐ฎ๐น
Thanks, but as explained in #3427171-6: Replace calls to ::expectWarning*() in Drupal\Tests\user\Kernel\Views\HandlerFilterRolesTest โ , replacing
expectError
withexpectException
is not sufficient for PHPUnit 10 compatibility. - ๐ฌ๐งUnited Kingdom longwave UK
I think this should trigger a deprecation in 10.3.x and an exception in 11.x.
- ๐ฌ๐งUnited Kingdom longwave UK
Actually given that this isn't really an error, we can just ignore and carry on, then I think an assertion is more appropriate?
- Status changed to Needs review
4 months ago 5:26pm 4 April 2024 - ๐ฌ๐งUnited Kingdom longwave UK
longwave โ changed the visibility of the branch 3427177-replace-calls-to to hidden.
- Status changed to RTBC
4 months ago 5:51pm 4 April 2024 - Status changed to Needs review
4 months ago 9:21am 5 April 2024 - ๐ฌ๐งUnited Kingdom alexpott ๐ช๐บ๐
Wouldn't throwing an exception be more helpful here? It feels really odd to change something from an irrecoverable error to an assertion.
- Status changed to RTBC
4 months ago 11:45am 5 April 2024 - ๐ฎ๐นItaly mondrake ๐ฎ๐น
Initially I thought PHPUnit removing expectError/Warning methods was a bad idea, but now seeing how everyone has a different perspective on 'what' a triggered error/warning is and means and how it should be impacting runtime, I changed my mind... PHP future is likely without error handlers, then. Only exceptions.
@alexpott input was addressed.
RTBC
- ๐ฌ๐งUnited Kingdom longwave UK
Yeah, I totally get it - exceptions are more manageable because they can be caught in a useful place in the call stack. You can still have a fatal error if you don't catch the exception, but I can imagine here if someone needed to they could catch this further up in the renderer stack and just not render this section of output - it gives everyone more options. Similarly, logging PHP level warnings seems dated now we have assertions, which fail harder than warnings for developers but still let us continue in production.
- ๐ฌ๐งUnited Kingdom alexpott ๐ช๐บ๐
It's the "still let us continue in production." bit that always makes me shudder.
Committed and pushed b59e63e990 to 11.x and 3d645c1b3c to 10.3.x. Thanks!
-
alexpott โ
committed 3d645c1b on 10.3.x
Issue #3427177 by longwave, quietone, dineshkumarbollu, samit.310@gmail....
-
alexpott โ
committed 3d645c1b on 10.3.x
- Status changed to Fixed
4 months ago 12:23pm 5 April 2024 -
alexpott โ
committed b59e63e9 on 11.x
Issue #3427177 by longwave, quietone, dineshkumarbollu, samit.310@gmail....
-
alexpott โ
committed b59e63e9 on 11.x
Automatically closed - issue fixed for 2 weeks with no activity.