Skip to content

Conversation

@rodnaph
Copy link
Contributor

@rodnaph rodnaph commented Apr 27, 2018

Related to #125, adds configuration validation that the classes passed to skip_capture exist.

Copy link
Contributor

@Jean85 Jean85 left a comment

Choose a reason for hiding this comment

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

Hello there, and thanks for the contribution!
I appreciate the fix, but I think that the current solution is a bit "harsh". Using class_exists can make the whole app fail if the string is no longer a loadable class, like if the containing package got removed/updated; I would prefer a softer approach... Any suggestion? Maybe a regex, like /^\\?\w+(\\\w+)*$/?

@rodnaph
Copy link
Contributor Author

rodnaph commented May 2, 2018

Hey, thanks for the review. I don't have any "softer" ideas for how this could be handled sorry...

What brought me to add this patch was that I erroneously put in a class to match, and was looking to make this more fool-proof. For me, I'd prefer it to be as strict as possible so I was alerted of invalid configuration - but I understand if that's not the behaviour you want for this library.

@Jean85
Copy link
Contributor

Jean85 commented May 2, 2018

Well, I think that the regex should be enough, because the set of possible strings that are valid FQCN are pretty simple... Basically all the cases are:

  • \SomeGlobalNamespacedClass
  • \Some_PSR0_NamespacedClass
  • \Some\Namespaced\Class

And other 3 without the starting \. You should rewrite your test with those 6 cases in the data provider and use a regex to validate it.

@mcfedr
Copy link
Contributor

mcfedr commented May 25, 2018

I guess the sense would be that if you put in a class that cannot be loaded, you probably made a mistake, crashes at container build time should be noticeable before you deploy

@stayallive
Copy link
Collaborator

Just a little thing to think about: I am not sure when that configuration is loaded but I assume on every request to Symfony so that could possibly add a lot of autoloading overhead.

@mcfedr
Copy link
Contributor

mcfedr commented May 25, 2018

The configuration is only run at compile time, this code wouldnt be run for every request

@stayallive
Copy link
Collaborator

Than you can ignore my comment completely 😄

@Jean85
Copy link
Contributor

Jean85 commented May 25, 2018

I guess the sense would be that if you put in a class that cannot be loaded, you probably made a mistake, crashes at container build time should be noticeable before you deploy

Yes, but that would be considered a BC; so I'm not inclined into implementing it like this in a minor/patch.

@Jean85
Copy link
Contributor

Jean85 commented Dec 12, 2019

Closing as stale. Feel free to reopen on top of master.

@Jean85 Jean85 closed this Dec 12, 2019
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.

4 participants