[All] Overridden 'canCreate' methods should always log an error message when they fail

[jnbrunet]

Now pretty much all overridden 'canCreate' found in the kernel or the modules behave as they should, which is, always specify why a component with the given template cannot be created in the given context.

This is the continuation of the PR #1266

---

This PR:

• builds with SUCCESS for all platforms on the CI.
• does not generate new warnings.
• does not generate new unit test failures.
• does not generate new scene test failures.
• does not break API compatibility.
• is more than 1 week old (or has fast-merge label).

Reviewers will merge only if all these checks are true.

[jnbrunet]

[ci-build][with-all-tests]

[hugtalbot]

what is the difference betweem msg_error and arg->logError ?

[damienmarchal]

Hi Hugo,

The idea is to let the calling function to detect and print the error. This is why the errors are logged in the object instead of sent via the msg_error API. I think this is not a satisfactory solution because it is an approach to error management that is very invasive.

I think a much better way of doing that would be to use a frame based message handler (as what was done with the EXPECT_MSG_ and EXPECT_NO_MSG_ for testing tests).
This would allow to write:

{ 
         MessageCatcher mc;

         tito();
         canCreate();

         if( mc.hasErrorMessage() )
         {
               msg_error(mc) << "reformat and re-emit the messsages "  < mc.msg();    
         }
}

which is actually very close to

try {
        
} catch(Error& m){
               throw Error("reformat and re-emit the messsages "+m.msg()); 
}

[hugtalbot]

thanks @damienmarchal

[jnbrunet]

Hi @damienmarchal and @hugtalbot

The object creation can be a little bit confusing. Here the arg->logError does not necessary mean that an error occurred. It is there to specify why a given object with a given template and a given context cannot be created.

For example, look at the following scene:

<Node>
    <MechanicalObject template="Vec3" />
    <TriangleFEMForcefield />
</Node>

And here is what the object creation for the TriangleFEMForcefield could look like:

1. TriangleFEMForcefield<Vec2Types>
   Does it have a mechanical object with Vec2Types in the current context?
   NO
   logError("No mechanical object with vec2Types found in the current context")
2. TriangleFEMForcefield<Vec3Types>
   Does it have a mechanical object with Vec3Types in the current context?
   YES
   -> Instanciate a new TriangleFEMForcefield<Vec3Types>
   -> No error shown since at least one combination of the object/template is valid

Now, let's change the mechanical object by giving him an incompatible template:

<Node>
    <MechanicalObject template="Vec2Rigid" />
    <TriangleFEMForcefield />
</Node>

And here is what the object creation for the TriangleFEMForcefield could look like:

1. TriangleFEMForcefield<Vec2Types>
   Does it have a mechanical object with Vec2Types in the current context?
   NO
   logError("No mechanical object with vec2Types found in the current context")
2. TriangleFEMForcefield<Vec3Types>
   Does it have a mechanical object with Vec3Types in the current context?
   NO
   logError("No mechanical object with vec2Types found in the current context")
   -> The object factory cannot instantiate a TriangleFEMForcefield object because:
   a. No mechanical object with vec2Types found in the current context
   b. No mechanical object with vec3Types found in the current context

Here the real error is that no TriangleFEMForcefield can be instantiated
The logError are there to specify what combinations of object/template were tried and why they failed.

Here's a real example of the failed creation of a component:

Hopefully that clear things up a little bit

[hugtalbot]

I don't get why sometimes getMeshTopologyLink and some other getMeshTopology
which seem to be two interface for both static and dynamic topologies but they are identitical !

[jnbrunet]

They are both doing the same thing, but getMeshTopology is more frequent, so I changed this one and hopefully at some point no one will be using getMeshTopologyLink and we will be able to safely remove it.

[hugtalbot]

Ok agreed. I created an issue to highlight this work in progress: #1297

[jnbrunet]

[ci-build][with-all-tests]