On Fri, 16 May 2025 19:18:28 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>> It just seems unnecessary to add all this complexity. The first exception >> is all we need, really - we can skip the 2nd, 3rd, ... This might rule out >> the property. >> >> It might be unlikely that two or more completely unrelated failures would >> happen in the field in a well-tested application [citation needed], I think >> there is a little value in trying to add this complex logic per timer. A >> static boolean might suffice. > > On the other hand, AnimationTimer is a public API that allows for arbitrary > code execution, which always has the potential to fail for any number of > reasons (think of calling an unstable API from the timer callback). We can’t > rule that out entirely. This is only a fallback in any case, as a well-tested > application shouldn’t throw exceptions from timer callbacks in the first > place. I've removed the system property, so there's a hard-coded limit of 100 exceptions now. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2094109661
