If the scope is limited to unit tests, the log message could also be intercepted in the test and interpreted as a failure (or success) without throwing any exceptions. As a consumer, I would be surprised and interpret it as a bug if a filter was to throw exceptions. From the separation of concern paradigm I see it as yet another feature, a concept of "interceptors" or something similar with a word that fits better. Those interceptors, again, could intercept messages with filters.
On Fri, 11 Oct 2024, 22:48 Gary Gregory, <garydgreg...@gmail.com> wrote: > On Thu, Oct 10, 2024 at 4:09 AM Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > Hi Gary, > > > > On Wed, 9 Oct 2024 at 16:34, Gary D. Gregory <ggreg...@apache.org> > wrote: > > > My proposal is to allow a user to _not_ define any custom filters by > > reusing a new Result enum value called “Throw”. When a filter returns > > “Throw”, then Log4j throws a new LoggingException subclass called > > FilterLoggingException. > > > > I find Log4j's 3-valued filtering system already very complex: > > > > - it is difficult or impossible to make a composite filter for a > > moderately complex boolean expression. If you have 3 filters that > > check A, B and C, how do you make a filter for `(A OR B) AND C ? > > ACCEPT : NEUTRAL`? > > > > I agree that the Filtering system should be different (maybe a predicate > tree instead of an array to allow for boolean logic), but these types of > changes are way beyond anything I am describing. I am proposing a new > feature that fits into the existing system and that would prevent users > from writing custom code that is beyond what a casual developer would be > comfortable doing (IMO). > > Gary > > > > - the difference between `ACCEPT` and `NEUTRAL` is never used, except > > for global filters[1]. > > - writing global filters requires a lot of knowledge about Log4j. For > > example the `Throwable` associated with a log event, can be hidden in > > one of 3 parameters (see the second `local/script.groovy` example in > > the documentation[2]. > > > > Given that I am not eager to complexify filters with yet another possible > > result > > > > Piotr > > > > PS: Note, Logback solves the boolean expression in a simple way: it > > has an `EvaluatorFilter` that uses a tree of `Predicate<LogEvent>` > > components to decide, which result to output. > > > > [1] > https://logging.apache.org/log4j/2.x/manual/filters.html#logger-stage > > [2] https://logging.apache.org/log4j/2.x/manual/filters.html#Script > > >
