mix logger.error(String format, Object... arguments) and logger.error(String msg, Throwable t)

[ManfredSchenkIOSB]

from time to time I am missing some kind of combination of the methods mentioned in the discussion title. Within a catch clause I'm trying to log some parameters as well as the Exception. At the moment, I construct the msg text by myself, but a mix of the methods would be nice. The same is true for all methods taking a Throwable as parameter.

But I see there are points in favor of such a method and also against this method:

positive:

• similarity (You can always use the formatter approach)
• reduced overhead when Level is not enabled

negative:

• Breaking API change ( the Throwable would have to be the first parameter to be compatible with the Object... parameter)
• no real performance gain for the use case error (The Level error will probably be active in nearly all situations, and Throwables are most likely logged with Level Error)

Any opinions on this?

[ceki]

@ManfredSchenkIOSB Are you aware of this faq entry?

Note that starting with 2.0.0, you can also write

 try {
 } catch(Exception ex) {
   logger.atError().setMessage("Hello {}").addArgument("world").setCause(ex).log();
 }

[ManfredSchenkIOSB]

Now I am aware of the faq entry :-) . But if I understand correctly, the faq entry only handles the case where there is only one additional parameter besides the Throwable.

[ceki]

Actually, any number of parameters, including 0, 1 or more.

[JacksonBaileyHM]

Unless I am misunderstanding you, this is actually already possible. See here. Basically when the last argument is a Throwable and doesn't match to any {} in the format string then it treats it similarly to error(String, Throwable).

String s = "Hello world";
try {
  Integer i = Integer.valueOf(s);
} catch (NumberFormatException e) {
  logger.error("Failed to format {}", s, e);
}

It would be nice if this were clearly mentioned in the Javadoc on the methods though. I forget it often myself. (In fact that's why I stumbled here, wondering if it could be added.) It is (in my opinion, cryptically) mentioned here in the Javadoc.

[q3769]

The SLF4J API supports parametrization (of 1 or more objects) in the presence of an exception, assuming the exception is the last parameter.

Sorry but that is a bad idea for a strongly-typed language like Java. Giving special treatment for an argument simply because of its position in a method's signature is a convention-based approach that should have been replaced by one that is based on the argument's type.

Why not simply put the "Throwable" type as the very first argument in the Logger.log(Throwable t, String message, Object... args) signature? It seems to be straight-forward API design 101. What am I missing?

Yes, the fluent API in version 2.x is nice but that doesn't solve the earlier bad API design as-is.

[prdoyle]

I'm a fan of strong types, but the badness of the current API is being overstated.

A few facts I think we can agree on, for context:

• Java has positional parameters; it's the nature of the language.
• If the types overlap, you can accidentally swap two of the parameters and encounter a problem. This is also the nature of the language.
• Log formatting is sensitive to parameter order regardless of exceptions. Swap the order and your log message will look funny.

What you are proposing might help the compiler report a situation where someone meant to have an exception provided as the cause but instead printed it into their format string. It would catch only this case, and no other case of log parameters having the wrong order. And when this case occurs, the application will not experience any errors or other bad behaviour; the log entries will just be missing some information.

Yes, it's conceivable that your change might theoretically catch the occasional bug whose consequences are relatively minor. The cost of your change is that we will have, for the first time ever, a logging method with positional arguments whose first argument is not the message string. This will look odd and counterintuitive to a lot of users. Yes, this cost is low, but so is the benefit, so it can't be ignored.

The fluent API already fixes this anyway.

[q3769]

Most oo languages have the positional param feature, but that doesn't mean it's the good way to do everything. On the contrary, using the strong type feature over position is a, if not the, big point of oo. That's the reason for the proposed signature.

The argument against "for the first time" is really hard to understand. The way things get done should depend on the merit of the approach, rather than other things. Compared to the overall merit, the first or the millionth time it's done should not carry that much weight.

The proposed signature is more for human/semantics, not for compiler/syntax. The current signatures would be less confusing if an argument takes different semantics at each and every different position; but it only takes on the exception semantics if it is the last in position - that is a confusion that can be addressed by a strongly typed alternative.

[prdoyle]

Fair. I just mean, when I'm using a logging API, I expect the first parameter to be the message. Sticking something else in front will make it less readable.

However, having said that, in most cases it will look like error(e, "Message goes here") (because people often call exceptions e). Even I can admit that's no big deal. 😄

[q3769]

BTW having Throwable as the first arg is not new for other logging APIs, e.g.

• https://tinylog.org/v2/logging/#exceptions

or to toot my own horn:

• https://github.com/elf4j/elf4j-api#the-logger-api

[prdoyle]

Heheh ok I yield.

[MpoMp]

This has been the source of much confusion and some mistakes in many companies I've worked in.
Personally I disagree with this hidden spec detail, it makes matters complicated and error-prone.

But even if it has to be there, it should be stated on the method-level Javadoc as well.