Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Messenger] Add StackInterface, allowing to unstack the call stack #28943

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

Merged
merged 1 commit into from
Oct 25, 2018

Conversation

nicolas-grekas
Copy link
Member

Q A
Branch? 4.2
Bug fix? no
New feature? no
BC breaks? yes
Deprecations? no
Tests pass? yes
Fixed tickets -
License MIT
Doc PR -

At the moment, debugging an exception coming from a middleware is not as friendly as it could: each middleware is preceded by a noisy frame added by the $next callable indirection.

This PR allows removing this frame by using $next()->handle($envelope, $next); instead of $next($envelope); in a middleware. Note that this is optional so that the later continues to work. But if one wants to opt-in for the former, then the stack trace of exceptions will be freed from $next.

All core middleware should do this, so here they are, updated.

@@ -23,11 +23,3 @@
*/
public function handle(Envelope $envelope, callable $next): void;
Copy link
Contributor

@ro0NL ro0NL Oct 23, 2018

Choose a reason for hiding this comment

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

worth to describe the callable signature / different modes in the phpdoc?

Copy link
Contributor

Choose a reason for hiding this comment

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

ah it's pretty clear in NextInterface, @see NextInterface maybe?

Copy link
Member Author

Choose a reason for hiding this comment

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

that's what the @param annotation already links to to me

Copy link
Contributor

Choose a reason for hiding this comment

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

sorry i missed that

Copy link
Contributor

@sroze sroze left a comment

Choose a reason for hiding this comment

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

As discussed IRL, this adds a lot of complexity to the way the middleware are called. I don't think that it's worth it, just for a few items in the stack trace (suggestion in a comment).

@sroze
Copy link
Contributor

sroze commented Oct 25, 2018

Maybe we can simplify the $next (and get out of the inner-stack), instead of having a function, we could give it the stack in the middleware:

public function handle(Envelope $envelope, StackInterface $stack): Envelope
{
    // ...

    return $stack->next()->handle($envelope, $stack);
}

return $middleware;
}

public function handle(Envelope $envelope, callable $next): void
Copy link
Member

Choose a reason for hiding this comment

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

why should this class implement MiddlewareInterface ? Calling it as a middleware does not make sense

@nicolas-grekas nicolas-grekas force-pushed the messenger-unstack branch 2 times, most recently from 38326a7 to ccce2b8 Compare October 25, 2018 12:45
@nicolas-grekas
Copy link
Member Author

public function handle(Envelope $envelope, StackInterface $stack)

I love that ;) @stof that fixes also your comment.
Now implemented. Ready.

@nicolas-grekas nicolas-grekas changed the title [Messenger] Add NextInterface, allowing to unstack the call stack [Messenger] Add StackInterface, allowing to unstack the call stack Oct 25, 2018
Copy link
Contributor

@sroze sroze left a comment

Choose a reason for hiding this comment

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

As discussed IRL, I like it. It's much more explicit. And it solves our stack-trace burden.

@sroze
Copy link
Contributor

sroze commented Oct 25, 2018

Thank you @nicolas-grekas.

@sroze sroze merged commit 2bc7d11 into symfony:master Oct 25, 2018
sroze added a commit that referenced this pull request Oct 25, 2018
…the call stack (nicolas-grekas)

This PR was merged into the 4.2-dev branch.

Discussion
----------

[Messenger] Add `StackInterface`, allowing to unstack the call stack

| Q             | A
| ------------- | ---
| Branch?       | 4.2
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | yes
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

At the moment, debugging an exception coming from a middleware is not as friendly as it could: each middleware is preceded by a noisy frame added by the `$next` callable indirection.

This PR allows removing this frame by using `$next()->handle($envelope, $next);` instead of `$next($envelope);` in a middleware. Note that this is optional so that the later continues to work. But if one wants to opt-in for the former, then the stack trace of exceptions will be freed from `$next`.

All core middleware should do this, so here they are, updated.

Commits
-------

2bc7d11 [Messenger] Add `StackInterface`, allowing to unstack the call stack
@nicolas-grekas nicolas-grekas deleted the messenger-unstack branch October 26, 2018 11:11
fabpot added a commit that referenced this pull request Oct 27, 2018
…agi)

This PR was merged into the 4.2-dev branch.

Discussion
----------

[Messenger] Move MiddlewareTestCase in Test ns

| Q             | A
| ------------- | ---
| Branch?       | master <!-- see below -->
| Bug fix?      | no
| New feature?  | yes <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes (AppVeyor failure unrelated)    <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A   <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | N/A

Just a quick suggestion after #28943 being merged. Wouldn't it make sense to move this in `Test` namespace to be used by anyone wanting to unit test their middleware?

Commits
-------

215c895 [Messenger] Move MiddlewareTestCase in Test ns
This was referenced Nov 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants