ObjectPath XML errors feedback

[MelReyCG]

This PR aims:

1. To prevents crashing when PathCollection::objectPath is wrong (thus, solving the case 2.1 of the issue #2320)

2. Add a context in case of a wrong PackCollection or FieldSpecification objectPath so we know from which object the error comes from (thus, solving the case 2.2 of the issue #2320).
In order to output the name of the Group with a wrong objectPath, this PR propose to use the GEOSX_THROW macros and try-catch to add a context to the originally thrown exception (inserting a line starting with ***** ERROR:):

***** ERROR: initialPressure has a wrong objectPath. The following error have been thrown:
***** LOCATION: /appli_PITSI/MelvinRey/GEOSX_repos/GEOSX/src/coreComponents/mesh/MeshObjectPath.cpp:225
***** Controlling expression (should be false): !foundMatch
***** Rank 0: elementRegionsGroup doesn't have a child named badRegion.
elementRegionsGroup have the following children: reservoir, wellRegion

3. To fix Group::getPath() so it no longer starts with m/ but with / (that m was the end of Problem which seemed wrongly cut). This fix will help a bit to output clearer path errors (this was the only use of getPath()). The returned path would be of the following form: /Tasks/myPackCollection (the leading / symbolizing it is an absolute path)
I added testGroupPath to test:

• the getPath() output,
• the getGroupByPath() input,
• if the Group hierarchy keeps being as we expect.

[klevzoff]

Sorry to chime in uninvited and this late into the PR's lifecycle, but I find the whole approach of parsing error messages and attempting to insert text in the middle logically "backwards" and extremely brittle. If someone changes the message format in LvArray logging macro and replaces 5 stars with 4 or something, this functionality might be silently broken.

Not to stand in the way of merging this as is (it is an improvement for end users), but we should consider an overall change to how throwing macros work: instead of adding all the extra formatting (rank number, stars, etc.) at the source of throw, we should throw just the succinct error message and add all the other stuff at the end (when the message gets printed). This will allow us to easily "stack" multiple contexts (messages) line-by-line as the exception propagates up the call stack, without having to parse the previous text. We could even preserve the original exception object and wrap it in the new one that gets re-thrown (e.g. nested_exception). This would be a separate PR, if anyone has free cycles to do it.

[TotoGaz]

the whole approach of parsing error messages and attempting to insert text in the middle logically "backwards" and extremely brittle.

You're absolutely correct. I think we would better keep the initial information of the exception in a more meaningful way (not in a raw string). But I'd expect this to be a significantly larger amount of work... And maybe we would even have to deal with the python bindings and I'm totally unaware on how it works.

If someone changes the message format in LvArray logging macro and replaces 5 stars with 4 or something, this functionality might be silently broken.

Most likely not, since this would result in broken unit tests.

Not to stand in the way of merging this as is (it is an improvement for end users), but we should consider an overall change to how throwing macros work: instead of adding all the extra formatting (rank number, stars, etc.) at the source of throw, we should throw just the succinct error message and add all the other stuff at the end (when the message gets printed). This will allow us to easily "stack" multiple contexts (messages) line-by-line as the exception propagates up the call stack, without having to parse the previous text. We could even preserve the original exception object and wrap it in the new one that gets re-thrown (e.g. nested_exception).

This surely makes sense, but...

... if anyone has free cycles to do it.

... this is the eternal issue.

[TotoGaz]

So why did you convert GEOSX_THROW_IF into GEOSX_THROW here?

[MelReyCG]

I forgot to change them back, I previously used std::vector to store the names.