lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Van Den Berghe, Vincent" <Vincent.VanDenBer...@bvdinfo.com>
Subject Proposal: Use innerexception to facilitate debugging
Date Wed, 04 Jan 2017 06:51:34 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message