How to handle the exception in AWT-EventQueue-0?

Question

This is my code:
import javax.swing.JFrame;
public class MainFrame extends JFrame {
     public MainFrame(){
          init();
     public void init(){
          setSize(100,100);
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JButton;
public class SubFrame extends MainFrame implements ActionListener{
     private JButton button1 = null;
     public SubFrame(){
          super();
     public void init(){
          super.init();
          button1 = new JButton("button1");
          add(button1);
          button1.addActionListener(this);
     public void actionPerformed(ActionEvent e) {
          // TODO Auto-generated method stub
          button1.setEnabled(false);
      * @param args
     public static void main(String[] args) {
          // TODO Auto-generated method stub
          (new SubFrame()).setVisible(true);
}When I click the button, this exception will be thrown:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
     at swing.SubFrame.actionPerformed(SubFrame.java:23)
     at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
     at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
     at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
     at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
     at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
     at java.awt.Component.processMouseEvent(Component.java:6038)
     at javax.swing.JComponent.processMouseEvent(JComponent.java:3265)
     at java.awt.Component.processEvent(Component.java:5803)
     at java.awt.Container.processEvent(Container.java:2058)
     at java.awt.Component.dispatchEventImpl(Component.java:4410)
     at java.awt.Container.dispatchEventImpl(Container.java:2116)
     at java.awt.Component.dispatchEvent(Component.java:4240)
     at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
     at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
     at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
     at java.awt.Container.dispatchEventImpl(Container.java:2102)
     at java.awt.Window.dispatchEventImpl(Window.java:2429)
     at java.awt.Component.dispatchEvent(Component.java:4240)
     at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
     at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
     at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
     at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

Answer 1

Darryl.Burke wrote:
Hmm. Interesting sequence of execution.
+-- new SubFrame () calls the sub class constructor
+----  which calls the super class constructor explicitly
+------  which calls init () of the sub class
+--------  which calls init () of the super class
and only after all these calls return, the declaration-cum-assignment of button1 is executed, which makes button1 null.
(Discovered by putting a breakpoint on that line and debugging in NetBeans)
With one change, button1 will not be null and the breakpont is not reached.private JButton button1;// = null;What's not clear is why the declaration-cum-initialization takes place after the constructor code executes, shouldn't it run before the constructor?
It does run before the SubFrame constructor, but it runs after the super class constructor, which is exactly how the language specification says it should be.
There was a similar thread a while back:
http://forum.java.sun.com/thread.jspa?threadID=5190252&messageID=9745092
Note that there is another "bad" habit involved (other than explicitly initializing member variables to null): that an overridden method is called from the super class constructor. That means that the overridden method will be executed before the object it belongs to has been fully initialized, and that will often lead to confusing behavior like this.