-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[RFC] Exceptions that suggest your missing package #25256
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
Comments
in the Debug component? |
ahah, this is on my todo-list. Not sure where that would be best though. |
Locally to every failure IMHO. There need to be an inventory somewhere. And I fear maintaining that in a separate location will be unmaintainable. We could also keep the messages, but add a method on exception classes like "setMissingComponent", and use that in some generic renderer. |
I don't think that putting this in the messages is sustainable. @weaverryan's example is good to show that it won't be possible to add something about the component to be installed with such exception. The thing that is installed with every Symfony skeleton application is the |
Yea, I agree with @sroze: I'm not sure this is really possible (the missing Twig function is a good example) by calling a One option would be to create a new repository that contains just this data and add that as a dependency to |
…ningful exceptions (nicolas-grekas) This PR was merged into the 3.4 branch. Discussion ---------- [TwigBundle/Brige] catch missing requirements to throw meaningful exceptions | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #25256, symfony/webpack-encore#173 | License | MIT | Doc PR | - It is possible to register a handler for undefined twig functions/filters. IMHO, this is the hook point we should leverage to throw meaningful exception messages. This works well on its own. We now just need to list the functions/filters with appropriate messages. There is one case we could enhance: at warmup time, Twig exceptions are swallowed, thus not visible. Shouldn't we make these visible instead? ping @weaverryan since this is related to two issues of yours. Commits ------- ac891ac [TwigBundle/Brige] catch missing requirements to throw meaningful exceptions
@fabpot what's the way forward to improve the DX here?
…On Sat, 30 Dec 2017 at 12:43, Fabien Potencier ***@***.***> wrote:
Closed #25256 <#25256>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#25256 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAxHEQ395gnKiprkxOCA3eLrNSimuSo5ks5tFiHhgaJpZM4QyvFa>
.
|
Well, it was solved for Twig filters/functions specifically.... So the question now is: can/should we just continue to solve these issues one-at-a-time as we discover them? Or should we add a more over/arching system. Right now... I can’t be sure... but I think we may be able to solve this on a case-by-case basis. |
The negative of Flex is that if you try to use a feature that's not installed, you'll get an error. Recently, we updated the exception messages in
ControllerTrait
to suggest the package that the user is missing when necessary.But there are so many other cases. For example, if you use
{{ asset() }}
in Twig without theAsset
component:Idea: Add new dev-only behavior that somehow enhances this error page to add a:
We would maintain a list of error patterns/strings and what package is needed somewhere. This could even be stored in Flex itself, so that it could be updated easily and more often.
The text was updated successfully, but these errors were encountered: