Fix NPE when calling refresh before getting a config at all #237

ibauersachs · 2021-11-22T22:33:59Z

Closes #234

nresare

This seems fine to me. One could argue that making refresh always succeed would make this a tiny bit more straight forward, but I have no strong opinion about this. Approved.

ibauersachs · 2021-11-23T13:08:06Z

This seems fine to me. One could argue that making refresh always succeed would make this a tiny bit more straight forward, but I have no strong opinion about this. Approved.

I'm not sure what you mean. Do you see a case where it still fails?

nresare · 2021-11-23T18:28:25Z

I just meant that if we want ResolverConfig.refresh() to always succeed, even when configProviders have not yet been set, we can do that. That would be less fragile than making sure that refresh() is only called after checkInitialized() is called.

My preferred solution would be to move the init code from checkInitialized() to the constructor, as that would man that partially initialised objects (where configProviders are not yet set) would never exist.

ibauersachs · 2021-11-23T18:53:23Z

I just meant that if we want ResolverConfig.refresh() to always succeed, even when configProviders have not yet been set, we can do that. That would be less fragile than making sure that refresh() is only called after checkInitialized() is called.

My preferred solution would be to move the init code from checkInitialized() to the constructor, as that would man that partially initialised objects (where configProviders are not yet set) would never exist.

configProviders is static, so I cannot completely avoid having checkInitialized() in getCurrentConfig() and getConfigProviders(). But I can move the first part into the constructor, keeping only currentConfig == null to eventually call refresh.