[DX] Show the ParseException message in all YAML file loaders

[fancyweb]

Q	A
Branch?	3.4
Bug fix?	no
New feature?	no
Deprecations?	no
Tickets	-
License	MIT
Doc PR	-

This PR synchronizes the exception message in the Routing, Validator and Translation YAML file loaders with the DependencyInjection YAML file loader behavior. Adding the ParseException message is a big DX gain because it highlights the problem directly instead of having to scroll down 7 previous exceptions.

I'm targetting 3.4 because DX can be considered as a bug fix AFAIK.

[nicolas-grekas]

as @stof spotted, all these should be moved outside sprintf()

[nicolas-grekas]

(but this is for master)

[javiereguiluz]

This is great! Thanks a lot @fancyweb!

I tested it in the Symfony Demo app and the difference is huge:

Before

After

[fabpot]

Idea: instead of selectively add the previous exception message to the current exception message, what about doing something similar to some Go error handling libraries where the end message of an error is always the concatenation of all error messages. That's something we could do only in the exception page/profiler.

[fancyweb]

as @stof spotted, all these should be moved outside sprintf()

You mean concatenating the exception message after the sprintf? sprintf('The file "%s" does not contain valid YAML', $file).': '.$e->getMessage()

[nicolas-grekas]

@fancyweb yes - we should also fix existing messages.

[fancyweb]

I fixed the existing message in the DI YamlFileLoader. Should I apply fabbot exception message formatting here, ie get rid of the : and just concatenate with a space + $e->getMessage()?

[nicolas-grekas]

Showing all stacked messages in a more prominent way is absolutely required I agree. The error page currently is not clear enough in this regard (I recently stayed stuck on an exception because I missed the 2nd one which provided the real issue.)

Doing both this change and improving the error page looks like what we should do IMHO. The reason is that we don't have full control over all situations where error messages are used; e.g. exceptions in logs, etc.

Still for master on my side - at least that's the policy we've had in the past: that's improving something.

[javiereguiluz]

I agree with @nicolas-grekas about the possible improvements in the error page. We'll discuss about this in the coming weeks to have it ready for Symfony 5.2 👍

[nicolas-grekas]

Thank you @fancyweb.