RFC: Injected previous exception into field validation exception

[alongosz]

🎫 Issue	n/a

Question after reading this: Does this provide enough value?

Description:

Note

The issue in ibexa/migrations, which I was trying to fix, actually no longer exists on 4.x - by accident - due to https://github.com/ibexa/migrations/pull/338. However I still believe this change presents some minor value.

Background

OOTB validation message returned by ContentFieldValidationException::getMessage states "Content fields did not validate".
To avoid lack of verbosity here (user doesn't know where the error actually is) we have there static method createNewWithMultiline,
however it still needs to be called explicitly when handling the exception thrown from some places, while in other places it has been wrapped already. Leaving this as-is due to BC.

Fix

This PR adds the possibility to include previous exception thrown when building new one using ContentFieldValidationException::createNewWithMultiline. Seems it is more correct to do:

try {
 // ...
} catch (ContentFieldValidationException $e) {
  throw ContentFieldValidationException::createNewWithMultiline($e->getFieldErrors(), $contentName, $e);
}

however due to the mentioned migrations fix, provides little actual value - just improving here the exception API itself.

Ideally I would do:

throw ContentFieldValidationException::createNewWithMultiline($e);

but that can't be done due to BC.

Additionally I've fixed broken PHPDoc for ContentService::publishVersion. Long time ago we've added the possibility to validate a content item during publishing instead of a create/update operation, but seems we've forgotten to document an exception that can be thrown.

For QA:

Not reproducible on 4.6 due to the mentioned migrations fix.

Documentation:

Rest API reference change for 4.6, not sure if extra doc action is needed here.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[alongosz]

Seems we don't need this as it was resolved for 4.6 in a different way. Closing.