@Araq As "the guy who receives all logged errors as email" in my "day job" project, I must point out that you're wrong in your assumption; "... the process dies ..." is simply wrong in our case (and hopefully in many other Java apps; you must get _something_ for the cost of that gigantic heap requirement and stop-the-world GC). That might be one of the greatest strength of Java (it only dies if you want it to). When an exception comes, and I see literally 1000s of occurrences every day (after merging repeated exceptions from the same client for the same operation), it is logged and, depending on the code location, some data might be thrown away, but the process just carries on (the exception to the rule is "corrupt Web-Start caches"). This applies in particular for OOM exceptions. I spent _ages_ making both our client and servers "OOM safe". Most of the time, when one client connection to a server causes an OOM, the other clients don't even notice, except the request might take longer due to a possible retry.
When I see some new exception in some place, I get the hotline to call the clients. About half of the time, the clients were _not aware_ that any exception occurred. That is in large part due to my personal contribution to the project. Corporate environment cares mostly about "client visible" errors. That is why dev time for deep refactoring is rarely granted. Of course, it could be different at other companies. Considering logging to a DB, I’m kind of ambivalent. The “unspecified text format” is a pita (I’m also “the guy that has to grep errors in the logs”). But we log exclusively to local drives. Mainly, because local drives don’t randomly get overloaded or crash, as some remote DB might do. Also we never log so much that it becomes a bottle-neck, which could happen when logging to a (presumably SQL) DB. (I’ll eat a broom the day we are allowed to use Kafka ...)
