issue #2207 - add type-checking for lists in fhir-model constructors

[lmsurpre]

if a clever user adds objects of the wrong type to the builder (via
reflection), we were never catching this and so the data could become
corrupted

Signed-off-by: Lee Surprenant lmsurpre@us.ibm.com

[JohnTimm]

Per our conversation, I think that:

if (Objects.isNull(element)) {
    throw new IllegalStateException(String.format("Repeating element: '%s' does not permit null elements", elementName));
}
Class<?> elementType = element.getClass();
if (!type.isAssignableFrom(elementType)) {
    throw new IllegalStateException(String.format("Invalid type: %s for repeating element: '%s' must be: %s", elementType.getSimpleName(), elementName, type.getSimpleName()));
}

or

if (Objects.isNull(element)) {
    throw new IllegalStateException(String.format("Repeating element: '%s' does not permit null elements", elementName));
}
if (!type.isInstance(element)) {
    throw new IllegalStateException(String.format("Invalid type: %s for repeating element: '%s' must be: %s", element.getClass().getSimpleName(), elementName, type.getSimpleName()));
}

are both easier to read / understand than the current structure because it is painfully obvious that we are performing a null check followed by a type check on each repeating element. Combining things into an outer if and inner if-then-else structure seems less clear to me. Other than that, LGTM.

NOTE: I also tweaked the error messages (above) to be more consistent with the rest of what's in the ValidationSupport class.

[michaelwschroeder]

LGTM - one minor comment

[JohnTimm]

LGTM