Before this commit, runtime exception is swallowed silently.

For example, if two StructuredLoggingJsonMembersCustomizer add same key, exception is printed now:

Exception in thread "main" java.lang.IllegalStateException: The name 'test' has already been written
    at org.springframework.util.Assert.state(Assert.java:101)
    at org.springframework.boot.json.JsonValueWriter.writePair(JsonValueWriter.java:228)
    at org.springframework.boot.json.JsonValueWriter.write(JsonValueWriter.java:83)
    at org.springframework.boot.json.JsonWriter$Member.write(JsonWriter.java:650)
    at org.springframework.boot.json.JsonWriter$Members.write(JsonWriter.java:339)

Comment From: philwebb

This is an interesting problem. I'm not sure if JsonWriterStructuredLogFormatter is the best place to fix it. Perhaps org.springframework.boot.logging.logback.StructuredLogEncoder and org.springframework.boot.logging.log4j2.StructuredLogLayout might be better. It's interesting that logback doesn't handle encoder problems directly.

Comment From: quaff

This is an interesting problem. I'm not sure if JsonWriterStructuredLogFormatter is the best place to fix it. Perhaps org.springframework.boot.logging.logback.StructuredLogEncoder and org.springframework.boot.logging.log4j2.StructuredLogLayout might be better. It's interesting that logback doesn't handle encoder problems directly.

Amended as your suggestion.

Comment From: mhalbritter

I assumed that Logback would handle any exception raised in an encoder. If that's not the case, StructuredLogEncoder and StructuredLogLayout should print them.

Comment From: philwebb

Thanks for the PR @quaff. Looking into this in more detail, I'm not sure that we should be printing the exception ourselves. It looks like we perhaps should be hooking into more of the logging library features to deal with errors. I've opened #43384 to track that.