<Swing Dev> [10] RFR JDK-6267105:UIDefaults.getUIError dumps error message to System.err and also throws Error.

[Sergey Bylokhov]

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.veerabhadraiah at oracle.com <mailto:shashidhara.veerabhadraiah at oracle.com>>; swing-dev <swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>>; Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>>; Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170619/39bdf975/attachment.html>