Model.Add() silently drops invalid GeoObjects (inconsistent overload behavior) — define a safer, explicit strategy

[dsn27]

Context

PR #292 proposes removing the HasValidData() check from Model.Add(IGeoObject) to avoid unexpected behavior when importing/working with geometries that may temporarily be invalid. We don’t want to merge the PR as-is, but we do want to address the real problem it highlights.

Current behavior

Model.Add(IGeoObject) currently does:

if (!ObjectToAdd.HasValidData()) return;

This means invalid objects can be silently ignored when added via this overload.

Other overloads (e.g. Add(GeoObjectList...), Add(IEnumerable...)) do not apply the same check, so behavior differs depending on which overload is used.

Even with this check, the Model can still end up containing invalid geometry (e.g., by editing data after adding, via a property editor or similar), so code cannot fully rely on “Model contains only valid objects”.

Why this is a problem

Silent failure is fragile: callers may assume an object was added, but it wasn’t.

Inconsistent API: different overloads behave differently.

Real workflows need “temporarily invalid” geometry:

importing imperfect data

allowing users to fix geometry after import

intermediate states during editing/interactive construction

Goals

• Make Add behavior predictable and consistent across overloads.
• Keep interactive construction robust (don’t casually pollute the model with garbage geometry).
• Support import and repair workflows where invalid geometry must be carried intentionally.

Possible approaches (to discuss)

• Keep the validity check, but don’t fail silently
• Throw an exception (or return a status) when invalid objects are rejected.
• Optionally include diagnostic info (type, reason, etc).
• Introduce an explicit “unsafe”/“allow invalid” path e.g. AddUnsafe(IGeoObject) / AddAllowInvalid(...)
• Make the caller opt-in so it’s clear when invalid geometry enters the Model.
• Unify overload behavior
• Decide whether all Add(...) overloads enforce the same rule.

If not, document clearly which APIs validate and which don’t.