Amusingly enough, we used to have almost the same exact sneaky throws
utility method in Throwables. I guess that was removed at some point.
On Thu, Nov 5, 2020 at 09:24 Volkan Yazıcı wrote:
> I have pushed 56436a to release-2.x. Would you mind taking a look at it,
> please? If there are no objec
I have pushed 56436a to release-2.x. Would you mind taking a look at it,
please? If there are no objections, I want to port it to master as well.
On Wed, Oct 28, 2020 at 9:05 PM Volkan Yazıcı
wrote:
> Hello,
>
> While logging, we sometimes notice that the entire logging infra comes to
> a halt,
Agreed. Scala has a notion of non fatal exceptions which basically matches
this.
On Wed, Oct 28, 2020 at 19:32 Ralph Goers
wrote:
> You might as well catch Throwable. You can’t really handle out of memory
> errors - the JVM won’t let you. As for StackOverflowError - yes, that
> should be handled
You might as well catch Throwable. You can’t really handle out of memory errors
- the JVM won’t let you. As for StackOverflowError - yes, that should be
handled. We don’t want the application to fail due to a buggy logging plugin.
Ralph
> On Oct 28, 2020, at 2:17 PM, Gary Gregory wrote:
>
> H
I could see rethrowing vm errors in some cases but we definitely don't want to
allow logging to stop entirely when these things occur.
On Wed, Oct 28, 2020, at 17:17, Gary Gregory wrote:
> Hi, I am not sure it is wise to catch VM Errors like out of memory and
> stack overflow Errors... any though
Hi, I am not sure it is wise to catch VM Errors like out of memory and
stack overflow Errors... any thoughts on those?
Gary
On Wed, Oct 28, 2020, 16:05 Volkan Yazıcı wrote:
> Hello,
>
> While logging, we sometimes notice that the entire logging infra comes to a
> halt, even though the rest of t
You are correct. Log4j should handle everything except an OOM error.
Ralph
> On Oct 28, 2020, at 1:05 PM, Volkan Yazıcı wrote:
>
> Hello,
>
> While logging, we sometimes notice that the entire logging infra comes to a
> halt, even though the rest of the application still works perfectly fine.
Good catch, I recall a similar bug using fully asynchronous logging when the
exception handler threw an error:
https://issues.apache.org/jira/browse/LOG4J2-2333
While it's generally not considered good practice to "handle" errors, in this
case it's far better than not logging! I've seen this ma
Hello,
While logging, we sometimes notice that the entire logging infra comes to a
halt, even though the rest of the application still works perfectly fine. I
have figured, appenders wrapped by AsyncAppender can throw a
java.lang.Throwable that is not a subclass of java.lang.Exception and such
an
