Re: Signaling configuration errors

I think the failures you note should cause the whole configuration to fail. The user should be able to control whether that failure surfaces an exception to the application. Ralph > On Mar 3, 2025, at 4:53 AM, Piotr P. Karwasz > wrote: > > Hi all, > > Configuration problems in our builders

Re: Signaling configuration errors

This issue was first raised in #3088 . There I already stated We shouldn't have partially applied configurations. I suggest [...] throwing exceptions in component initialization failures, and catching them in `ConfigurationBuilder::build` metho

Re: Signaling configuration errors

lable due to a file-lock or a network issue the configuration is discarded - a subsequent reload has no more information about the failed configuration - it is simply gone. Cheers, Jeff From: Gary Gregory Sent: Monday, March 3, 2025 2:39 PM To: Apache

Re: Signaling configuration errors

I like the idea of a transactional configuration (all or nothing). Internally I think we should use a custom unchecked runtime exception which would be logged by us from our top level API. Gary On Mon, Mar 3, 2025, 06:54 Piotr P. Karwasz wrote: > Hi all, > > Configuration problems in our builde

Signaling configuration errors

Hi all, Configuration problems in our builders are handled in multiple ways: 1. Sometimes we call `LOGGER.error` and return `null`. 2. Sometimes we throw an explicit exception. The types of exceptions vary: NPE, IllegalArgumentException, IllegalStateException, etc. There is a `o.a.l.l.core.co