Improve Your Exceptions Logging with Tinylog 2.1

tinylog is a lightweight logging framework that offers several interesting features for logging exceptions and normal text messages. Besides the Java logging API, there are also special logging APIs for Kotlin and Scala. However, we will use the default Java logging API in this article, since Java is the most commonly used programming language.

Boilerplate-free Logging API

When logging on Java, you typically create a logger instance at class level for issuing any log entries. For example, logging an exception with SLF4J:

When using tinylog, neither a logger instance nor an explicit error message for an exception is required:

The main logger class of tinylog’s logging API is static. Therefore, log entries can be issued without first creating a logger instance. However, tinylog will resolve the class, in which a log entry has been issued, at runtime. In tinylog, the output of location information such as class name, method name, and line number is very fast (see benchmark). The output format for log entries can be configured via a format pattern.

Unlike SLF4J, exceptions can be logged without a message. In tinylog, messages are optional, if exceptions are logged. However, a message can be placed after the exception, if desired: Logger.error(ex, "My custom message") .

Clearer Exceptions with Reduced Stack Trace

Depending on the technology stack, stack traces can become very long, especially when using web frameworks and/or Hibernate. Since version 2.1, tinylog can filter exceptions and stack traces to make the output clearer and show only relevant stack trace elements.

One possibility is to define a list of packages and classes to be removed from the stack trace. This is exactly what the strip throwable filter in tinylog does.

Let’s create a tinylog.properties configuration that writes log entries into the log.txt file and removes the packages org.hibernate and sun.reflectand the class java.lang.reflect.Method from stack trace:

Now let’s assume the following exception would be thrown and logged via tinylog:

After logging the above exception, you will find the following log entry in the log file:

Additional Throwable Filters

Besides the strip throwable filter, tinylog contains three additional throwable filters. The unpack throwable filter allows, for example, to unpack a cause throwable from a wrapper exception. This is useful, for example, if the real checked exception has been wrapped by a RuntimeException, because a called method doesn't allow to throw the checked exception. By using the unpack throwable filter, tinylog can undo the wrapping and output only the checked exception.

There is also a keep throwable filter, which works like the strip throwable filter in the example above. But in opposite to the strip throwable filter, you can define a list of packages and classes to keep. All stack trace elements that are not in the defined list are removed, when outputting stack traces.

The last one is the drop cause throwable filter, which removes all causes from a throwable. It only outputs the root throwable.

How to Continue

Further information and a complete documentation of tinylog can be found on the project website. The logging framework is open source under the Apache License 2. So, tinylog can be used in both private and commercial projects. The tinylog logging API can even be used on Spring and Java EE application severs by using one of the official adapters.