Re: Avoiding NPEs caused by indirect call

From:

Pavel <dot_com_yahoo@paultolk_reverse.yourself>

Newsgroups:

comp.lang.java.programmer

Date:

Mon, 04 Aug 2008 00:00:54 GMT

Message-ID:

<WErlk.285831$SV4.196979@bgtnsc04-news.ops.worldnet.att.net>

Royan wrote:

On 3 ???, 19:45, Lew <com.lewscanon@lew> wrote:

Royan wrote:

This is just an example:
public class Model extends AbstractModel {

...

Your example is incomplete.
<http://pscode.org/sscce.html>

Also, you failed to cite (copy and paste) the exception message.

We need more information.

PS
There is a an erroneous cross-post in java.gui, please ignore it

That was not a cross-post, that was a multi-post. A cross-post shows all
addressed groups in one message. A multi-post shows the same or similar
message independently as several messages, one per group. Cross-posting is
better than multi-posting.

If clj.gui and clj.programmer had different readerships, it would have been
pointless to tell clj.programmer to ignore clj.gui, wouldn't it?

--
Lew

Hi Lew,

There is not much sense in stack trace, it's classic problem, i'm only
looking for the best solution. If stack really matters here's slightly
improved example that you can even run yourself and stack trace:

package test;

import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;

public class Model extends AbstractModel {
    private final PropertyChangeSupport propertyChangeSupport;

    public Model (Object source) {
        propertyChangeSupport = new PropertyChangeSupport(source);
    }

    @Override
    public void addPropertyChangeListener(PropertyChangeListener
listener) {
        propertyChangeSupport.addPropertyChangeListener(listener);
    }

    @Override
    public void firePropertyChange(String propertyName, Object
oldValue, Object newValue) {
        propertyChangeSupport.firePropertyChange(propertyName,
oldValue, newValue);
    }

    public static void main(String[] args) {
    new Model(new Object());
    }
}

abstract class AbstractModel {
    public AbstractModel() {
    indirectCall();
    }

    private void indirectCall() {
    setSomeValue(new Integer(1));
    }

    public void setSomeValue(Integer value) {
        firePropertyChange("someProperty", null, value);
    }

    public void addPropertyChangeListener(PropertyChangeListener
listener) {
    // some code
    }

    protected void firePropertyChange(String propertyName, Object
oldValue, Object newValue) {
        // some code
    }
}

I guess, you know the simple answer: program cannot use object state
until the object is fully constructed. There is no generic guard against
this situation in Java -- not that I know, anyway; supposedly, C++ has
one but in fact the situation there is even worse: you cannot call a
virtual method of a derived class until its constructor is entered --
even if that virtual method does not use any state specific to the
derived class -- which is no fun either.

....
> I could add validation: if(propertyChangeSupport == null)
> {super.firePropertyChange(...)} but this is also kind of a hack
> which I don't really like.

I guess this is what you have to do in Java. C++ would have called the
right virtual method automatically; for the flexibility we have in Java,
we have to pay by pointing out explicitly what method we want to call.
In my practice, I have been never hit by this Java opportunistic
behavior but suffered from the corresponding C++ limitation several
times -- apparently your mileage differs. I do not think it is possible
to have it both, so somehow in Java you need to explicitly choose the
correct method.

-Pavel