Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Unwrap errors in FlattenException#26028

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@derrabus
Copy link
Member

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?maybe
Deprecations?no
Tests pass?no (but probably unrelated?)
Fixed tickets#26025
LicenseMIT
Doc PRN/A

This is probably the most straightforward way to solve#26025.FlattenException is now unwrappingFatalThrowableError instances and logs the wrapped error instead. The consequence of this change is that the real error class is displayend on TwigBundle's exception page and the profiler.

Regarding BC: If we assume thatFlattenException is used for rendering and logging, everything should be fine. But this PR changesFlattenException's internal behavior. If a piece of code relied on errors appearingFatalThrowableError inside aFlattenException, that code would break.

bildschirmfoto 2018-02-02 um 20 08 42

Koc reacted with thumbs up emoji

publicfunction__construct(\Throwable$e)
{
$this->throwable =$e;

Choose a reason for hiding this comment

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

We should only keep the class name, not the instance, to make this lighter

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

We then would need to keep the original message as well, becauseFatalThrowableError tinkers with it. But yes, I can change that.

Choose a reason for hiding this comment

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

then would need to keep the original message as well

Let's remove the tinkering yes

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Okay, I'll remove it.

nicolas-grekas added a commit that referenced this pull requestFeb 3, 2018
…rabus)This PR was merged into the 2.7 branch.Discussion----------Removed unused parameter from flattenDataProvider()| Q             | A| ------------- | ---| Branch?       | 2.7| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | no, but unrelated| Fixed tickets | N/A| License       | MIT| Doc PR        | N/AWhile working on#26028, I noticed that FlattenExceptionTest::FlattenExceptionTest.php() exposes two arguments although all tests consuming that provider only use the first one. This PR removes the unnecessary second argument.Commits-------d6f4f51 Removed unused parameter from flattenDataProvider().
// assertEquals() does not like NAN values.
$this->assertEquals($array[$i][0],'float');
$this->assertTrue(is_nan($array[$i++][1]));
$this->assertNan($array[$i][1]);

Choose a reason for hiding this comment

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

should be revert as discussed previously

derrabus reacted with thumbs up emoji
@derrabus
Copy link
MemberAuthor

The fabbot failure can be ignored, see#26030 (comment)

@nicolas-grekas
Copy link
Member

Thank you@derrabus.

@nicolas-grekasnicolas-grekas merged commitf14d7d6 intosymfony:masterFeb 4, 2018
nicolas-grekas added a commit that referenced this pull requestFeb 4, 2018
This PR was merged into the 4.1-dev branch.Discussion----------Unwrap errors in FlattenException| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | maybe| Deprecations? | no| Tests pass?   | no (but probably unrelated?)| Fixed tickets |#26025| License       | MIT| Doc PR        | N/AThis is probably the most straightforward way to solve#26025. `FlattenException` is now unwrapping `FatalThrowableError` instances and logs the wrapped error instead. The consequence of this change is that the real error class is displayend on TwigBundle's exception page and the profiler.Regarding BC: If we assume that `FlattenException` is used for rendering and logging, everything should be fine. But this PR changes `FlattenException`'s internal behavior. If a piece of code relied on errors appearing `FatalThrowableError` inside a `FlattenException`, that code would break.<img width="402" alt="bildschirmfoto 2018-02-02 um 20 08 42" src="https://user-images.githubusercontent.com/1506493/35760077-0b202940-087e-11e8-9b98-8e4ba269780c.png">Commits-------f14d7d6 Unwrap errors in FlattenException.
@derrabusderrabus deleted the display-error-class branchFebruary 4, 2018 15:04
fabpot added a commit that referenced this pull requestApr 6, 2018
…on (derrabus)This PR was merged into the 4.1-dev branch.Discussion----------[Debug] Support any Throwable object in FlattenException| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | yes| Tests pass?   | yes| Fixed tickets |#26429| License       | MIT| Doc PR        | N/AAlternative to#26447 without BC breaks, follows#26028.This PR removes the need to convert `Throwable` objects into exceptions when working with `FlattenException`.ping@instabledesign@ostrolucky@nicolas-grekasCommits-------96c1a6f Support any Throwable object in FlattenException.
@fabpotfabpot mentioned this pull requestMay 7, 2018
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@nicolas-grekasnicolas-grekasnicolas-grekas approved these changes

@chalasrchalasrchalasr approved these changes

Assignees

No one assigned

Projects

None yet

Milestone

4.1

Development

Successfully merging this pull request may close these issues.

4 participants

@derrabus@nicolas-grekas@chalasr@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp