Proposal: Use innerexception to facilitate debugging

["Van Den Berghe, Vincent" <Vi...@bvdinfo.com>]

Hello,

I get an "Object reference not set to an instance of an object" somewhere propagated from the ConcurrentMergeScheduler.MergeThread.Run() method. This is one of many different exceptions I get when I try to use Lucene.net in a highly concurrent environment. Lucene.net is not reliable, and I have yet to have a successful index generation. There seem to be a whole class of problems related to concurrency in Lucene.net. I'd like to track them down, but it's not simple, not even with debug builds.

To ease the pain somewhat, I would like to propose some minor changes. For example:

            /// <summary>
            /// Create a {@code MergeException}. </summary>
            public MergeException(Exception exc, Directory dir)
                : base(exc.Message)
            {
                this.Dir = dir;
            }

Replace the :

                : base(exc.Message)

With:

                : base(exc.Message, exc)

... so that the original exception with its stack trace is not lost.
In DefaultAttributeFactory, I've seen exceptions as well. The try/catch blocks are defined incorrectly and effectively mask the root cause. To avoid being chastised by rewriting it all, I would simply propose to pass the original exceptions as inner exceptions:

                    catch (ArgumentException e)
                    {
                        throw new System.ArgumentException("Could not instantiate implementing class for " + typeof(S).FullName, e);
                    }


                    catch (Exception e)
                    {
                        throw new System.ArgumentException("Could not find implementing class for " + attClass.Name, e);
                    }

This would somewhat alleviate the problem of tracking things down.

I still stand by my previous remark that temporary file generation is not thread safe, but it's out of my hands.

Thanks,

Vincent