log4s and failed FileAppender creation

[jtu...@objektfabrik.de]

Hi,

I think the following test should pass but it fails:

    self
        should: [
            EsLogManager rootLogger addAppender: (
                EsFileAppender
                    name: 'test'
                    layout: nil
                    threshold: EsLevel Info
                    fileName: 'C:\NonexistenPath\log.log'
                    fileAppend: false
                    immediateFlush: true)]
        raise: ExError.

    self should: [EsLogManager log: 'Some Log Entry'] raise: ExError.

    EsLogManager rootLogger removeAppender: 'test'


What do I mean by that? I think the creation of a File Appender should throw an exception if the file cannot be written. The result of creating a File Appender with an invalid path does not result in an exception but in a FileAppender that includes an EACCESS error in its instance variable #stream. So in reality, the first expression does not raise an exception, the first attempt to log does.

Just an anecdote for those who like anecdotes:
I've just learned the hard way that this can lead to interesting problems. We've had a hudson-driven build image that did its job like a clockwork for the duration of the full build process - it just couldn't log to the logfile. But it crashed in a very ugly way when the Appenders were shutDown (the image hangs and cannot access sources in the library any more and can only be quit using the Task Manager). So when I returned to our build server this morning, I had about 10 images lurking around in an unresponsive state and it took me a minute or two (what an euphemism) to understand what happened. Mady my monday morning ;-).
At least now I know I had an issue with catching logging exceptions in my build tools ;-)

Joachim

[jtu...@objektfabrik.de]

Just to add a little info:

To me it seems EsAppender>>#logError: should not only quietly log to TranscriptTTY but also throw an exception.
Or is the rationale behind all this that logging should never get into our way, even if it's broken? I would tend to disagree on this one.
But even if so, then the cleanup code is missing some checking for errors, obviously.

Joachim

[Donald MacQueen]

Joachim,

Thanks for the heads up. I will look into it.

On Nov 7, 8:09 am, "jtuc...@objektfabrik.de" <jtuc...@objektfabrik.de>
wrote:

[Marten Feldtmann]

I do not think that logError: should throw an exception ....

[jtu...@objektfabrik.de]

Marten,

I am not religious about exceptions for normal logging.

But I insist on an exception when Appenders cannot be created and made ready.

Otherwise you think all is well only to find out that your application crashes in some completely unrelated area because it tries to log onto an EACCESS...
It shouldn't throw an exception or crash at some place where the first logging is tried, but when the system realizes it won't be able to log. I can still decide to catch that exception and ignore it by removing the Appenders that won't work, if I am adventurous enough.

Of course, the logging itself can always go wrong when a disk is full, a socket is closed or whatever. You can always argue if that should be made visible to the user / developer or not. Maybe we need some log:ifError: variants for those who want to react to such situations.

Joachim