Great to see that the “log-error-and-throw” issue has been addressed and solved. Many thanks, much appreciated!

I wouldn’t go as far as far as describing this as a “security issue”, since any application following best-practices would use SQL parameters, and thus wouldn’t include any “secrets or personal information” in the SQL string itself – those would be in query parameters, which are not logged in this case.

Mike seems to agree in his earlier comment:

After digging into this a little more, I discovered that the root cause of this is actually in the PostgreSQL JDBC driver which includes the query parameters in a batch query exception

That being said, I find it weird that we log an error when we also re-throw an exception afterwards:

I’d be in favor of not logging anything and just re-throwing the exception, possibly wrapping it with another exception if necessary (we already do in the first example, but not in the second one)?

Note this also affects Keycloak negatively:

Hi guys! Despite this issue being reported 5 years ago, I want to bring it to attention again because it is still very relevant. Could someone from the Hibernate team explain why the “log-error-and-throw” approach is sometimes chosen in Hibernate (in certain situations and not always consistently)? In the most recent version, this still happens, for example, when a StaleStateException is thrown in BatchImpl (and only when batching is enabled).

In my opinion, when an exception is thrown from a library (like Hibernate) the decision to log an error is better left to the calling code. This is especially true in situations where the exception can almost always be automatically retried, such as with the StaleStateException (optimistic locking failure). Errors in the logs often cause alerts to be triggered, causing the need for engineers on duty to look into these “errors”. Currently, the only way to circumvent this is by suppressing these error logs (which is not something you want to do in general)

Can someone please shed a light on this? Perhaps there are good reasons for Hibernate to do so, but in that case I would be really interested to know them. Or perhaps any plans on fixing / improving this in the (near) future?

Many thanks!

After digging into this a little more, I discovered that the root cause of this is actually in the PostgreSQL JDBC driver which includes the query parameters in a batch query exception.

I do still think this should not log and throw