Output failing file on syntax error

[umulmrum]

If a source file fails to compile, the detector aborts with an error message like this:

[PhpParser\Error]
Syntax error, unexpected EOF on line 11

In large projects there might be abandoned files that don't even compile, so I think it would be great to have the path of the file that fails.

Perhaps it makes sense to continue the detection run even if some files fail.

[ghost]

Output has been corrected by #15, however execution is still halted

[ghost]

In order to continue execution, the \SensioLabs\DeprecationDetector\RuleSet\Traverser's constructor could have an additional $excluded parameter, which holds an array to directories and files to be excluded in traversing rulesets. This way a global configuration can be loaded to skip "broken" files

[derrabus]

Instead of maintaining a list of broken files, wouldn't it make more sense to catch the exception, report the file to be broken and skip it?

[ghost]

That would be the optimal way, however the current setup does not allow to catch the exception, and continue traversing on an application level. The catch would have to be implemented in the Traverser, which would have to report back to the application with a list of exceptions for the console output. Imho, that would be a rather ugly way.

As a quick thought, the Traverser could collect exceptions, continue working and the application could call a getter to print the exceptions.

[ghost]

Sorry, I have been looking at the ruleset generation, not the analysis of the own code. But we have here the same problem (previous comment is wrong), when calling the ParsedPhpFileFinder::getIterator we get the parser errors, but I cannot figure out a clean way to report those errors back to the caller without interrupting execution. I'll try out collecting them and have the caller ask for them.

[ghost]

The PR #30 should fix this issue now