Misplaced warning.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Misplaced warning.

tkellerer

Owen Thomas wrote:

> Hello.
>
>
> In the following code:
>
>         SynapseOwnerParticipant p=null;
>         try{
>             p=(SynapseOwnerParticipant)sender;
>         }catch(ClassCastException ex){/*Do nothing.*/}
>         if(p==this.getPrincipledQuale()){
>             p.reactToEngagementMessage(subscription,claimant,citation,sequence);
>         }
>
> Clearly to me, the code shows that the variable p will not be null
Well it can be null. If the exception is thrown, then nothing is done and p is not assigned, thus it stays null.

If this.getPrincipledQuale() also returns null, then p could be null inside the if statement.

The IDE can't know if this.getPrincipledQuale() never returns null, hence the warning.




Reply | Threaded
Open this post in threaded view
|

Re: Misplaced warning.

Owen Thomas-2
I suppose my question then is related to how far the IDE could go to check that the variable p is never going to be null when the method reactToEngagementMessage is called on it, and hence, how far the IDE could indeed go to determine the return value from getPrincipledQuale.

I use Netbeans a lot; it's a very good IDE for what I use it for. I don't think there are too many more dots for the IDE to connect in order to conclude that the return from getPrincipledQuale would never be null and that the variable p could never be null in order for the guarding condition to be true, The getPrincipledQuale method merely returns a value from a final field which is assigned from a parameter in the constructor. If this parameter is null, and exception will be thrown in the constructor. Hence. the field would never be null, and so neither will the return from getPrincipledQuale.

It might be a little bit of an enhancement to connect these extra dots (perhaps?) but I think it would certainly help make Netbeans even better.
 

On 18 April 2017 at 22:02, tkellerer <[hidden email]> wrote:

Owen Thomas wrote:
> Hello.
>
>
> In the following code:
>
>         SynapseOwnerParticipant p=null;
>         try{
>             p=(SynapseOwnerParticipant)sender;
>         }catch(ClassCastException ex){/*Do nothing.*/}
>         if(p==this.getPrincipledQuale()){
>             p.reactToEngagementMessage(subscription,claimant,citation,sequence);
>         }
>
> Clearly to me, the code shows that the variable p will not be null
Well it can be null. If the exception is thrown, then nothing is done and p is not assigned, thus it stays null.

If this.getPrincipledQuale() also returns null, then p could be null inside the if statement.

The IDE can't know if this.getPrincipledQuale() never returns null, hence the warning.





Reply | Threaded
Open this post in threaded view
|

Re: Misplaced warning.

Owen Thomas-2
The getPrincipledQuale method is declared in the superclass as follows:

    public final PQ getPrincipledQuale(){
        return this.principledQuale;
    }

The superclass’s constructor sets principledQuale with the following code:

    public Principle(PQ quale)throws CliqueSpaceException{
        if(quale==null){
            throw new Principle_PrincipledQualeNotGiven(); // A CliqueSpaceException
        }
        this.principledQuale=quale;
    }

Hence, the IDE would only need to look this far to determine that getPrincipledQuale would never return null.



On 18 April 2017 at 22:28, Owen Thomas <[hidden email]> wrote:
I suppose my question then is related to how far the IDE could go to check that the variable p is never going to be null when the method reactToEngagementMessage is called on it, and hence, how far the IDE could indeed go to determine the return value from getPrincipledQuale.

I use Netbeans a lot; it's a very good IDE for what I use it for. I don't think there are too many more dots for the IDE to connect in order to conclude that the return from getPrincipledQuale would never be null and that the variable p could never be null in order for the guarding condition to be true, The getPrincipledQuale method merely returns a value from a final field which is assigned from a parameter in the constructor. If this parameter is null, and exception will be thrown in the constructor. Hence. the field would never be null, and so neither will the return from getPrincipledQuale.

It might be a little bit of an enhancement to connect these extra dots (perhaps?) but I think it would certainly help make Netbeans even better.
 

On 18 April 2017 at 22:02, tkellerer <[hidden email]> wrote:

Owen Thomas wrote:
> Hello.
>
>
> In the following code:
>
>         SynapseOwnerParticipant p=null;
>         try{
>             p=(SynapseOwnerParticipant)sender;
>         }catch(ClassCastException ex){/*Do nothing.*/}
>         if(p==this.getPrincipledQuale()){
>             p.reactToEngagementMessage(subscription,claimant,citation,sequence);
>         }
>
> Clearly to me, the code shows that the variable p will not be null
Well it can be null. If the exception is thrown, then nothing is done and p is not assigned, thus it stays null.

If this.getPrincipledQuale() also returns null, then p could be null inside the if statement.

The IDE can't know if this.getPrincipledQuale() never returns null, hence the warning.






Reply | Threaded
Open this post in threaded view
|

Re: Misplaced warning.

Owen Thomas-2
Sorry the declaration of principledQuale in the superclass is:

    private final PQ principledQuale;

That should complete all necessary conditions for the IDE to conclude that getPrincipledQuale would never return null.

On 18 April 2017 at 22:44, Owen Thomas <[hidden email]> wrote:
The getPrincipledQuale method is declared in the superclass as follows:

    public final PQ getPrincipledQuale(){
        return this.principledQuale;
    }

The superclass’s constructor sets principledQuale with the following code:

    public Principle(PQ quale)throws CliqueSpaceException{
        if(quale==null){
            throw new Principle_PrincipledQualeNotGiven(); // A CliqueSpaceException
        }
        this.principledQuale=quale;
    }

Hence, the IDE would only need to look this far to determine that getPrincipledQuale would never return null.



On 18 April 2017 at 22:28, Owen Thomas <[hidden email]> wrote:
I suppose my question then is related to how far the IDE could go to check that the variable p is never going to be null when the method reactToEngagementMessage is called on it, and hence, how far the IDE could indeed go to determine the return value from getPrincipledQuale.

I use Netbeans a lot; it's a very good IDE for what I use it for. I don't think there are too many more dots for the IDE to connect in order to conclude that the return from getPrincipledQuale would never be null and that the variable p could never be null in order for the guarding condition to be true, The getPrincipledQuale method merely returns a value from a final field which is assigned from a parameter in the constructor. If this parameter is null, and exception will be thrown in the constructor. Hence. the field would never be null, and so neither will the return from getPrincipledQuale.

It might be a little bit of an enhancement to connect these extra dots (perhaps?) but I think it would certainly help make Netbeans even better.
 

On 18 April 2017 at 22:02, tkellerer <[hidden email]> wrote:

Owen Thomas wrote:
> Hello.
>
>
> In the following code:
>
>         SynapseOwnerParticipant p=null;
>         try{
>             p=(SynapseOwnerParticipant)sender;
>         }catch(ClassCastException ex){/*Do nothing.*/}
>         if(p==this.getPrincipledQuale()){
>             p.reactToEngagementMessage(subscription,claimant,citation,sequence);
>         }
>
> Clearly to me, the code shows that the variable p will not be null
Well it can be null. If the exception is thrown, then nothing is done and p is not assigned, thus it stays null.

If this.getPrincipledQuale() also returns null, then p could be null inside the if statement.

The IDE can't know if this.getPrincipledQuale() never returns null, hence the warning.