LoggerBackend

Interface for all logger backends.

Implementation Notes:

Often each AbstractLogger instance will be instantiated with a new logger backend to permit per-class logging behavior. Because of this, it is important that logger backends have as little per-instance state as possible.

It is also essential that no implementation of LoggerBackend ever holds onto user supplied objects (especially log statement arguments) after the log() or handleError() methods to which they were passed have exited.

This means that ALL formatting or serialization of log statement arguments or metadata values MUST be completed inside the log method itself. If the backend needs to perform asynchronous I/O operations it can do so by constructing a serialized form of the instance and enqueing that for processing.

Note also that this restriction is NOT purely about mutable arguments (which could change before formatting occurs and produce incorrect output), but also stops log statements from changing the lifetime of arbitrary user arguments, which can cause "use after close" bugs and other garbage collector issues.

See also