[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F [v3]
From:       Tejesh R <duke () openjdk ! java ! net>
Date:       2022-05-31 10:05:41
Message-ID: J1XPX7ANQP7964hw3MmG84T2ztIabWGtXHzae9yMyrQ=.73363b5a-9a37-4740-845b-9295f8fd5183 () github ! com
[Download RAW message or body]

On Tue, 31 May 2022 09:57:36 GMT, Alexey Ivanov <aivanov@openjdk.org> wrote:

> > Ok, then will try with the _bufferedImage paint_ logic, If I'm able to get the \
> > exception without it been handled by internal code then it'll be really helpful \
> > to make it automatic.
> 
> > > _Actually if the current test executes then its a pass right......?_
> > This means, if there is no NPE raised then its a pass case right.......?
> 
> Yes, no NPE means the test passes successfully. If NPE is thrown, the test fails.
> 
> > Yeah to some extent it is automatic, I actually didn't get how to handle the \
> > caught NPE, so just left it so that the Test case will be failed by NPE.
> 
> In the majority of cases, you don't want to catch exceptions in tests. No \
> exceptions are usually expected. An exception thrown from main makes the test fail. \
>  Yet I can't see how it gets thrown from main in this particular case. It's not \
> important, however.

Its not thrown from main I guess, its from internal code when JTable.update is \
called....... As I can see, painting the table to `BufferedImage` might not raise an \
exception in this case...... So I think its better to handle it by not handling or \
re-catching the NPE. I'll just remove the passFailFrame and the test case would be \
fine with that I guess......?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8830


[prev in list] [next in list] [prev in thread] [next in thread]