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

Hi Piotr/Gary, I don't know if this answers the "transaction" question - but a little input...as the Germans here say "giving my added mustard." 🙂 For my recent changes - adding builders to Filters replacing old factory methods I have been doing the following. 1. The single private construct

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