Skip to content

Document the handling of exceptions with listeners #4181

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.

Sign up for GitHub

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

Jump to bottom
Closed
stof opened this issue Aug 26, 2014 · 8 comments
Closed

Document the handling of exceptions with listeners #4181

stof opened this issue Aug 26, 2014 · 8 comments
Labels
actionable Clear and specific issues ready for anyone to take them. Stalled

Comments

@stof
Copy link
Member

stof commented Aug 26, 2014

Currently, the doc explains how to overwrite the error page rendered by the controller.
This is fine for apps wanting to make the error page look better by having them consistent with their styles.

However, the exception handling system of Symfony is much more flexible than that. This can be particularly useful if you throw domain-related exceptions in your codebase which should be rendered as client errors rather than a 500 page for instance.
The usage of listeners on the kernel.exception event allows to handle this case very easily, and without requiring to use subrequests and a controller. See symfony/symfony#11752 (comment) for the original discussion.
As a side note, this is exactly what the Security component does in core for the Symfony\Component\Security\Core\Exception\AccessDeniedException.

I don't know a public project using this approach (but I'm very far from knowing the codebase all open-source projects based on Symfony). However @weaverryan, I know that KnpLabs used this approach already in one of its project for which I saw the codebase when I was working there. So some of your colleagues should be able to show you this approach at least.
@weaverryan weaverryan added the actionable Clear and specific issues ready for anyone to take them. label Sep 16, 2014
@weaverryan
Copy link
Member

I think this is a nice idea and should be added to this page: http://symfony.com/doc/current/cookbook/controller/error_pages.html. Notice that we show 2 options at the top currently, and this should be 3. We can then add a short section at the bottom showing a quick example of throwing your own exception class and then catching it in a listener to render a custom error page.

Also, the 2 (soon to be 3) options at the top of this page should all contain links to the specific sections on this page. In other words, they should act like navigation.

@stof stof mentioned this issue Oct 4, 2014
Merged
@mpdude mpdude mentioned this issue Oct 4, 2014
Merged
@mpdude
Copy link
Contributor

mpdude commented Oct 4, 2014

Please consider #4294 as a starting point, although it currently lacks the example for custom exceptions in the third section.

weaverryan added a commit that referenced this issue Oct 17, 2014
@weaverryan
feature #4294 Improve cookbook entry for error pages in 2.3~ (mpdude)
44f570b 
This PR was merged into the 2.3 branch.

Discussion
----------

Improve cookbook entry for error pages in 2.3~

This PR cherry-picks the improvements from #4293 that apply to 2.3 as well (almost all!).

It also addresses some of the considerations in #4181.

Commits
-------

f74b6f2 Improve cookbook entry for error pages in 2.3~
@mpdude
Copy link
Contributor

mpdude commented Oct 17, 2014

#4294 has been merged. Let me know if you're still missing anything!

@wouterj
Copy link
Member

wouterj commented May 1, 2015

Imo, we should add some code in the third step to actually show you what's needed for an exception listener. The example from the Security component is a great use case, but the code itself contains a lot of lines, where as you only need some lines of code to get things rolling.

@mdburgos mdburgos mentioned this issue Jul 8, 2015
Closed
@xabbuh xabbuh added the hasPR A Pull Request has already been submitted for this issue. label Mar 31, 2016
@weaverryan
Copy link
Member

I've just closed the related PR #5503. This entry does need some work, and the whole thing should be reviewed and updated:

  • Using an event subscriber should be shown before overriding the controller. It's more robust. I'm not even sure if overriding the controller should ever be a good idea.

  • We should actually show an event subscriber code (and it should be a subscriber, not a listener).

  • In the subscriber, we should at least mention how you could handle a custom exception class.

@weaverryan weaverryan mentioned this issue Jul 20, 2017
Closed
@xabbuh xabbuh removed the hasPR A Pull Request has already been submitted for this issue. label Jul 20, 2017
@carsonbot
Copy link
Collaborator

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

@carsonbot
Copy link
Collaborator

Hello? This issue is about to be closed if nobody replies.

@wouterj
Copy link
Member

wouterj commented Jan 2, 2021

I think we can safely close this issue. The page has been revamped, following the changes in exception handling in Symfony (with the introduction of the ErrorHandler component).

@wouterj wouterj closed this as completed Jan 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
actionable Clear and specific issues ready for anyone to take them. Stalled
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@weaverryan @stof @wouterj @mpdude @xabbuh @carsonbot