Error class is a subclass of Throwable, so currently the code throw an Error
and immediately catch it, then print stack trace.
>
> Hi Sergey, The below marked stack trace would be hit if there is any
> exception raised while creating the Error object in the try block. But the
> user would still get the stack trace if the exception is not handled because
> the Error calls base class function of Throwable:
>
> public Throwable(String message) {
> fillInStackTrace();
> detailMessage = message;
> }
> <>
> The stack trace would be printed by the above code in Throwable
> implementation. I believe it is inevitable to print this because this is one
> of the basic level implementation and we do have an unhandled exception. And
> I don’t think I should do any change in here. Please let me know if you think
> otherwise.
>
> I have attached the test file which I used to test the user level effects.
> The user won’t be able to use the expressions like this
> (if(UIManager.getUI(comp) == null)) as mentioned in the JIRA bug but he will
> be able to use the below catching code:
> try {
> System.out.println("Updating UI");
> UIManager.getUI(comp);
> } catch (Exception e) {
> System.out.println("GetUI is null");
> System.out.println(e.getMessage());
> }
>
> The output of this is as follows:
> Updating UI
> GetUI is null
> Null
>
> If the there is no exception catch performed then it would have the below
> output:
> LAF State: [Custom LAF - CustomUI$1],LAF Class:
> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Exception in thread "main" java.lang.NullPointerException
> at
> java.desktop/javax.swing.MultiUIDefaults.getUIError(MultiUIDefaults.java:131)
> at
> java.desktop/javax.swing.UIDefaults.getUI(UIDefaults.java:790)
> at
> java.desktop/javax.swing.UIManager.getUI(UIManager.java:1065)
> at CustomUI.main(CustomUI.java:50)
>
> Process finished with exit code 1
>
> Please let me know if any part of my analysis is wrong or skewed.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, June 17, 2017 1:22 AM
> Cc: Shashidhara Veerabhadraiah <shashidhara.veerabhadra...@oracle.com
> <mailto:shashidhara.veerabhadra...@oracle.com>>; swing-dev
> <swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>>; Philip Race
> <philip.r...@oracle.com <mailto:philip.r...@oracle.com>>; Semyon Sadetsky
> <semyon.sadet...@oracle.com <mailto:semyon.sadet...@oracle.com>>
> Subject: Re: <Swing Dev> [10] RFR JDK-6267105:UIDefaults.getUIError dumps
> error message to System.err and also throws Error.
>
> Hi, Shashi.
> Can you please clarify the purpose of this fix, because the bug states that
> the code prints traceback to the system.err, even if the user tries to
> catch/suppress an exception.
> The current fix removed the system.err logging but the code which print trace
> still there:
> protected void getUIError(String msg) {
> try {
> throw new Error(msg);
> }
> catch (Throwable e) {
> e.printStackTrace();
> }
> }
> >> Through catching the error, the user can perform necessary recovery
> >> actions without cluttering the system.err
>
> I am not sure that the user is able to catch this error. So what is the
> difference when we had an additional message before and after the fix?
>
> >
> > +1
> >
> > --Semyon
> >
> >
> > On 06/12/2017 03:54 AM, Shashidhara Veerabhadraiah wrote:
> >> Hi All,
> >> Please review the code bug fix for
> >> JDK-6267105:UIDefaults.getUIError dumps error message to System.err and
> >> also throws Error.
> >>
> >> Issue:
> >> Error message was getting dumped to the system.err even though the
> >> recovery actions were performed leading to unnecessary confusion regarding
> >> the actual behavior.
> >>
> >> Fix:
> >> This fix removes the call which prints the message to the system.err
> >> and stores the message in the Error class. This same message can be
> >> retrieved after we catch the error and calling getMessage() of the Error
> >> class. Through catching the error, the user can perform necessary recovery
> >> actions without cluttering the system.err. This fix does not modifies the
> >> 'user effect' as the user would still get the same error as they were
> >> getting before this fix.
> >>
> >> Test:
> >> Now the system.err does not get cluttered though we performed the
> >> necessary recovery actions. The error message string can be recovered by
> >> calling getMessage() if needed.
> >> Bug:
> >> https://bugs.openjdk.java.net/browse/JDK-6267105
> >> <https://bugs.openjdk.java.net/browse/JDK-6267105>
> >>
> >> Webrev:
> >> http://cr.openjdk.java.net/~aghaisas/shashi/6267105/webrev_00/
> >> <http://cr.openjdk.java.net/~aghaisas/shashi/6267105/webrev_00/>
> >>
> >> Thanks and regards,
> >> Shashi
> >
>
>
> <CustomUI.JAVA>
