design choice when the mesh or mesh entities are used incorrectly

[nicolaslg]

When the user tries to call some functions not adapted to the mesh model we have a mixed bag of checks that throw exceptions and possible segfaults.

See in https://github.com/LIHPC-Computational-Geometry/gmds/blob/3e7dd077c7966b4b167079f0ff76162f0e60f0db/ig/src/Edge.cpp, where a call to Edge::nbEdges() can result in a segfault, or Edge::delegateGet(std::vector<Edge>& ACells) throws an exception when the model does not have E2E.

We could choose to always check, or we could use the NDEBUG macro that also deactivates asserts (I believe the RelWithDebInfo and Release build types both define it).

[franck-ledoux]

I'm pretty sure that we should keep using exception for high-level algorithms. For instance, when we develop a new algorithm class with an execute() method, we should enforce to also have a isValid() method that check the mesh consistency at the beginning.

For low-level ones, for instance at the cell level, like in Edge::nbEdges(), I would tend avoid exception. I may be wrong. We accept a set fault if we don't use it well and we raise exceptions in a debug mode