All EntityFS exceptions inherit FileSystemException, either directly or via some subclass. FileSystemException inherits RuntimeException which makes all EntityFS exceptions unchecked (see the Wikipedia article on checked exceptions).

In general, EntityFS methods do not try to handle any exceptions that they encounter; it is up to the client application to implement a strategy for that. Some classes with longer-running methods, such as the IteratorCopier, support an optional ErrorHandlingStrategy.

Every FileSystem uses a LogAdapter instance for logging. It is an adapter to the client application's logging system.

The following adapters are implemented:

Adapters to other logging systems can be created by implementing the LogAdapter interface.

The file system's current log adapter is always referenced by its LogAdapterHolder instance. The same holder object is used throughout the file system's lifetime and it is shared among all of the file system's objects that need to log.

By keeping the log configuration in an object instance, rather than in static class configuration like Commons Logging and JDK 1.4 logging do, the configuration of a LogAdapter instance is only visible to the objects that have a reference to it. This has the advantage of automatically limiting the scope of configuration changes without having to bother with different class loaders, thread locals and such. This is important in environments such as application servers where several different applications may share the same JVM and hence, often, the same class loaders. The obvious drawback is that an instance of the logger object has to be passed around to everyone that needs it. In EntityFS, this is not a big problem since most objects have a reference to their parent file system object anyway, and can get a LogAdapter from there.