I think it was more related to other uses of the same catching() method being spammy, not this particular one. Any error reporting from before the catching(e) code, though, I don't recall anymore.
On 21 June 2014 19:15, Remko Popma <[email protected]> wrote: > In that case it is back to spammy now; I changed the level to explicit > ERROR because of the issue I mentioned. > > Are errors thrown very often during initialization? (When you say spammy, > do you mean frequent or the fact that, if an error occurs, the full stack > trace is printed - which can be quite long?) > > Sent from my iPhone > > On 2014/06/22, at 8:26, Matt Sicker <[email protected]> wrote: > > I think it was using LOGGER.catching(e) which got rather spammy when we > changed the default logging level for catching from debug to error. > > > On 21 June 2014 10:07, Remko Popma <[email protected]> wrote: > >> While working on a new JUnit test I ran into this issue where no logging >> was happening and I saw this printed to system.err: >> >> ERROR StatusLogger Unable to invoke factory method in class class >> org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender for >> element RollingRandomAccessFile. >> ERROR StatusLogger Null object returned for RollingRandomAccessFile in >> Appenders. >> ERROR StatusLogger Unable to locate appender RollingRandomAccessFile for >> logger >> >> The problem is that this message does not explain the cause of the >> problem. To many users this message will just say "log4j is broken". >> >> It turned out that I had misconfigured the test (used >> a TimeBasedTriggeringPolicy while filePattern didn't have a date). >> >> That is key information that should be reported by the error handling. >> >> So... >> PluginBuilder.build() now has two try/catch blocks where the catch looks >> like this: >> } catch (final Exception e) { >> LOGGER.catching(Level.DEBUG, e); >> LOGGER.error("Unable to invoke factory method in class {} for element >> {}.", this.clazz, this.node.getName()); >> return null; >> } >> >> I am going to change change the DEBUG to ERROR, so we get this: >> LOGGER.catching(Level.ERROR, e); >> >> That will print a long-ish stack trace, which may not be the most >> user-friendly, but at least it will give the user the information they need >> to solve the problem. >> >> I don't know how error reporting worked before PluginBuilder, there may >> be a better format... Please feel free to improve on this. >> >> > > > -- > Matt Sicker <[email protected]> > > -- Matt Sicker <[email protected]>
