Broken build

[Sergey Mirvoda]

changeset 38.

All files in the analisys\attribute\token are missing.

Who is responsible for latest merges. You should fix the build ASAP:)

--
--Regards, Sergey Mirvoda

[Prescott Nasser]

I didn't do it - BUT I have a question.
 
I'm trying to take care of the exceptions, and ParseException requires Token to be implimented - but since that's in analysis we haven't done anything with it. Do I mock it out (and all the pieces it requires?) do I comment out lines that require Token for now? something else?
 
What's the best way to handle this?
 
~P


 

---

From: ser...@mirvoda.com
Date: Fri, 19 Nov 2010 13:38:51 +0500
Subject: [lucere-dev] Broken build
To: lucer...@googlegroups.com

--
You received this message because you are subscribed to the Google Groups "Lucere Development" group.
To post to this group, send email to lucer...@googlegroups.com.
To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lucere-dev?hl=en.

[Sergey Mirvoda]

Are you implementing tests?

--
--Regards, Sergey Mirvoda

[Prescott Nasser]

I was just doing the rest in the exceptions layer (looks like someone overwrote my changes where I added my name).
 
I suppose I should do test for them as well ? (sorry showing my novice skills here) - could you point me in the right direction for that?
 

index\CorruptIndexException.java	lucere.exception.CorruptIndexException	Unassigned
index\FieldReaderException.java	lucere.exception.FieldReaderException	Unassigned
index\StaleReaderException.java	lucere.exception.StaleReaderException	Unassigned
queryParser\ParseException.java	lucere.exception.ParseException	Unassigned
util\ThreadInterruptedException.java	lucere.exception.ThreadInterruptedException	Unassigned

index\CorruptIndexException.java	lucere.exception.CorruptIndexException	Unassigned
index\FieldReaderException.java	lucere.exception.FieldReaderException	Unassigned
index\StaleReaderException.java	lucere.exception.StaleReaderException	Unassigned
queryParser\ParseException.java	lucere.exception.ParseException	Unassigned
util\ThreadInterruptedException.java	lucere.exception.ThreadInterruptedException	Unassigned

index\CorruptIndexException.java	lucere.exception.CorruptIndexException	Unassigned
index\FieldReaderException.java	lucere.exception.FieldReaderException	Unassigned
index\StaleReaderException.java	lucere.exception.StaleReaderException	Unassigned
queryParser\ParseException.java	lucere.exception.ParseException	Unassigned
util\ThreadInterruptedException.java	lucere.exception.ThreadInterruptedException	Unassigned

 

---

From: ser...@mirvoda.com
Date: Fri, 19 Nov 2010 13:45:54 +0500
Subject: Re: [lucere-dev] Broken build

[Troy Howard]

Use lucere.analysis.query.parse.IToken for the referenced type...
Since it's not there yet, stub out the interface as an empty interface
in the correct location and someone else will do that one later.

Thanks,
Troy

[Troy Howard]

That would be Christopher... Who apparently got a lot of work done,
committed the .csproj, but didn't commit the .cs files it references.

Tsk tsk.. ;)

Thanks,
Troy

[Sergey Mirvoda]

as for me I have to created stub interfaces all the way 

since I'm on very top of the Lucene on IIndexSearcher
stub creation is not a problem with Reshaper.

all I need to do is to place stub file into right place 

--Regards, Sergey Mirvoda

[Troy Howard]

Prescott,

When creating a unit test, our goal is to test the contract that a class represents. 

So, we should always start with "What is the contract for this class?".

Exceptions tend to be very light on contract. For the most part, an exception exposes relatively few properties and most custom exceptions simply inherit directly from System.Exception and don't add any functionality or custom properties. 

Example: 

    public class MyException : Exception

    {

        public MyException(string message) : base(message)

        {

        }

    }

There's really nothing to test here. The only thing you could possibly test is that yes, when I pass a string in the constructor for 'message' parameter, the Message property contains the same string I passed in. 

But, according to Microsoft guidelines, exceptions should be serializable. Which means they need to Serializable attribute and the appropriate constructor. The example above doesn't have that.. So we don't need to test it, but assuming it was written correctly like this:

    [Serializable]

    public class MyException : Exception

    {

        //

        // For guidelines regarding the creation of new exception types, see

        //    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconerrorraisinghandlingguidelines.asp

        // and

        //    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp07192001.asp

        //

        public MyException()

        {

        }

        public MyException(string message)

            : base(message)

        {

        }

        public MyException(string message, Exception inner)

            : base(message, inner)

        {

        }

        protected MyException(

            SerializationInfo info, StreamingContext context)

            : base(info, context)

        {

        }

    }

Then we should unit test that it correctly serializes and deserializes... Since it doesn't add any behaviour or contract to the existing Exception type, testing this is kind of pointless. We can assume the BCL types function as expected. Regardless, if they don't we can't fix it.

But if it does add something... like for example this: 

    [Serializable]

    public class ParseException : Exception

    {

        //

        // For guidelines regarding the creation of new exception types, see

        //    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconerrorraisinghandlingguidelines.asp

        // and

        //    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp07192001.asp

        //

        public ParseException()

        {

        }

        public ParseException(string message)

            : base(message)

        {

        }

        public ParseException(string message, Exception inner)

            : base(message, inner)

        {

        }

        public ParseException(string message, IToken token)

            : base(message)

        {

            Token = token;

        }

        public ParseException(string message, IToken token, Exception inner)

            : base(message, inner)

        {

            Token = token;

        }

        protected ParseException(

            SerializationInfo info, StreamingContext context)

            : base(info, context)

        {

        }

        public IToken Token { get; private set; }

    }

We've added the Token property. Serialization may no longer work correctly if the Token instance is not serializable or custom serialization for that type didn't get implemented correctly. 

In the case of a custom property on an Exception like this, we should then have a unit test for each constructor, validating that the properties were correctly assigned via the constructor overloads and that serialization works as expected for all members.

This may seem like overkill for something as simple as an exception... but one rule of thumb is that there's no such thing as too many unit tests covering too many cases. I'd hate to try to debug something that had crashed, thrown this exception and then got a serialization exception when it tried to serialize it and it failed. It would hide the real problem which threw the first exception and I'd be scratching my head trying to figure out what went wrong with serialization, when what I should be focusing on is what went wrong with parsing. 

Your best bet is to avoid complex behaviour in an exception in the first place, as it's a bad place to introduce potentially faulty behaviour, since you only ever use them when something else has already failed. Can lead to the above described situation pretty quick and be a real brain drain for debugging.

Thanks,
Troy

[Sergey Mirvoda]

One question.

how to implement Serializable

public class Explanation implements java.io.Serializable

public interface IExplanation:ISerializable

or

[Serializable]

public interface IExplanation

[Troy Howard]

ISerializable is appropriate. 

[Troy Howard]

Also, see DIGY's comments in the "A bit lost" thread, where he discusses mapping java.io.Serializable ... Some good insight there. 

Thanks,
Troy

[Sergey Mirvoda]

o thanks.

How about moving such a questions\answers into CodePlex Docs?

[Troy Howard]

That's a great idea. If anyone would like to pick up the burden of sifting through the emails and turning them into readable documentation, that would be very helpful!

I tried to document some of it, but have only gotten stubs in there for most of it. 

Thanks,

Troy

[Digy]

When “System.Runtime.Serialization.ISerializable” is used private fields are not serialized. They sould be handled via “GetRealObject” and a special constructor which can be a tedious code.(Lucene needs that private fields)

On the other hand, using “[Serializable]” attribute allows serialization of private fields.

IMO, “System.Runtime.Serialization.ISerializable” should be avoided unless very necessary and “System.Runtime.Serialization.IObjectReference” should be used when a control is needed during serialization(like “intern”ing strings).

 

DIGY

[Sergey Mirvoda]

as for me I always think that you should use ISerializable only with [Serializable] when you need to tweak serialization process

[Troy Howard]

Sounds good to me. I defer to DIGY's experience on the matter and suggest that we follow his methodology.

Thanks,

Troy

[Sergey Mirvoda]

Guys 

IAttribute
and

IPayload

are missing from project

created some stubs. to compiling.