Archived

This forum has been archived. Please start a new discussion on GitHub.

perhaps a bug in pather.cs

In current 3.0.0 version, it seems that null object can not be returned from peer endpoints. If not intentionally, this seems a bug.

public override void patch(Ice.Object v)
{
Debug.Assert(type_ != null);

if (v!=null) // necessary?
{
if(!type_.IsInstanceOfType(v))
{
throw new System.InvalidCastException("expected element of type " + type()
+ " but received " + v.GetType().FullName);
}
}

value = v;

}


Best regards
OrNot

Comments

  • I'm not sure I understand why this might cause a problem. Do you have test case to show where this would cause incorrect behavior?

    Cheers,

    Michi.
  • hi, Michi,
    It is easy to reproduce this error if you add ,say, HelloI ,in server ,

    public class HelloI: Demo.helloDisp_
    {
    public override Demo.TestClass get(Ice.Current current__)

    {
    return null;
    }


    };

    That is, return a null reference to a object.



    Here are the original codes:

    public override void patch(Ice.Object v)
    {
    Debug.Assert(type_ != null);
    if(!type_.IsInstanceOfType(v))
    {
    throw new System.InvalidCastException("expected element of type " + type()
    + " but received " + v.GetType().FullName);
    }

    value = v;

    }

    When v is undefined, an exception is thrown.
  • Thanks for that, I'll have a look at this next week.

    Cheers,

    Michi.
  • Thanks muchly for the bug report! I've posted a patch here.

    Cheers,

    Michi.
  • Perhaps another bug in Patcher.cs

    Considering the fellowing slice definition:

    // **********************************************************************
    //
    // Copyright (c) 2003-2005 ZeroC, Inc. All rights reserved.
    //
    // This copy of Ice is licensed to you under the terms described in the
    // ICE_LICENSE file included in this distribution.
    //
    // **********************************************************************

    #ifndef HELLO_ICE
    #define HELLO_ICE
    module Demo
    {
    class Node;
    ["clr:collection"]sequence<Node> NodeList;

    class Node
    {
    NodeList subNode;
    };
    interface Hello
    {
    nonmutating void sayHello();
    Node getNode();
    };

    };
    #endif


    In the HelloI (say,Java sample codes):

    public class HelloI extends _HelloDisp
    {
    public void
    sayHello(Ice.Current current)
    {
    System.out.println("Hello World!");
    }

    public Node getNode(Current __current)
    {
    Node fatherNode = new Node();
    Node[] subNodes = new Node[2];
    fatherNode.subNode = subNodes;
    return fatherNode;
    }
    }


    That's, return some objects with null in a sequence.;


    This can result in an exception from Patcher.cs in client when the v==null,


    public override void patch(Ice.Object v)
    {
    try
    {
    if(_seq is IList)
    {
    if(_index >= _seq.Count)
    {
    for(int i = _seq.Count; i <= _index; i++)
    {
    ((IList)_seq).Add(dummyObject); // IList implementation does not permit adding null :-(
    }
    }

    ////////////////////////Exception from here////////////////////////////////
    /// ((IList)_seq)[_index] = v;
    ////////////////////////////////////////////////////////


    }
    else
    {
    ((System.Array)_seq).SetValue(v, _index);
    }
    }
    catch(System.Exception)
    {
    throw new System.InvalidCastException("expected element of type " + type()
    + " but received " + v.GetType().FullName);
    }
    }


    I am not very sure about this bug and maybe it is my useage mistake.


    OS: win2000;
    Vistual Studio 2003;
    Ice: 3.0.0;




    Cheers
    OrNot
  • Thanks for the bug report.

    The problem is caused by the IList methods of CollectionBase. Unfortunately, it does not permit null to be inserted into a list (God only knows why... :( ) and, to make things worse, the Add method and the indexer of the implementation of CollectionBase appear to be non-virtual, so the call isn't dispatched into the NodeList implementation :(

    I'm still investigating possible workarounds.

    Michi.
  • I've posted a patch for this problem. Thanks for reporting this!

    Cheers,

    Michi.