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 <pi...@mailing.copernik.eu> > wrote: > > 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.config.ConfigurationException`, but it doesn't seem to be used > often. > > 3. Sometimes exceptions, usually NPEs, are thrown by the constructor of a > plugin. Most of the time I consider these bugs. > > Could we agree on a preferred way to signal configuration errors? I don't > plan to modify the behavior of old code, but we should apply a consistent > strategy on new builders. > > I do like throwing exceptions, which often simplifies flow control, but when > I started working on Log4j, I was told 1. was the way to go. > > On a related matter, Ralph said on Slack that: > > > Failure during configuration should be caught and cause the previous > > configuration to remain intact. > > While I agree with this "all-or-nothing" strategy, this is not the way it > currently works. Regardless of the strategy chosen to communicate the > problem, a misconfigured component will simply be omitted. This can cause > problems down the line, like: > > 2025-03-03T11:49:26.081922076Z main ERROR RollingFileAppender 'ROLLING': When > no file name is provided a DirectFileRolloverStrategy must be configured > 2025-03-03T11:49:26.082046726Z main ERROR Null object returned for > RollingFile in Appenders. > 2025-03-03T11:49:26.083912635Z main ERROR Unable to locate appender "ROLLING" > for logger config "root" > > However, these problems are not fatal and the configuration replaces the > previous one. > > What do you think? > > Piotr >
