Throw exception when ROF can't initialize class properly.

[cwlucas41]

I was using ROF to create instances of a private nested class. ROF was able to give me an instance of the class but was unable to set the fields. The resulting object had all null fields. I was able to fix the issue by making the nested classes public.

Here is an example of the nested class:

@Getter

@Setter

private static class BaseObject {

    private String baseField;

}

ROF should have told me that it couldn't initialize the object properly instead of failing silently.

[overholts]

Such access to a private inner class is invalid, and the ensuing IllegalAccessException is eaten here:

try {
    setter.invoke(object, typedObjectFactory.create(genericSetterParamTypes[0]));
} catch (final IllegalAccessException | InvocationTargetException e) {
    // make setter invoke not fail on error
    // intentionally ignored
}

To provide a better user experience, we would need to detect when both all constructors and all setters can't be accessed. Since it handles the recursive instantiation of arbitrarily complex objects, failing gracefully is a pretty high priority for ROF. I think the best we could do here is log a warning, but it might suffice to call this out in the documentation.

[leakingtapan]

Another idea is to make this crash on fail behavior configurable. The default behavior is no failure on error. And user can set a configurable parameter Config.FAIL_ON_ERROR to true to flip the behavior. @cwlucas41 @overholts

[cwlucas41]

I no longer use the library, but (echoing Ben's words above) I think this is pretty important so that ROF fulfills it's promise of creating objects with randomized data and not failing silently in such cases.

The current behavior gives unexpected results in equality checks for classes with @EqualsAndHashCode since you'd expect ROF created instances to be unequal to each other. This could cause certain tests to pass that should actually fail.

I support the flag for backwards compatibility reasons, but I'd flip it to be safe by default and require an override for the legacy behavior.

[leakingtapan]

I support the flag for backwards compatibility reasons, but I'd flip it to be safe by default and require an override for the legacy behavior.

That's reasonable. Thx for the feedback. One concerns is this breaks existing behavior if we flip to crash on error.