lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: Exceptions in TestConcurrentMergeScheduler
Date Thu, 04 Oct 2007 10:04:20 GMT
Mike,

Would it work to have a common LuceneTestCase base class that could  
do that check and fail() in tearDown?

	Erik


On Oct 4, 2007, at 5:31 AM, Michael McCandless wrote:

>
> OK, I think I found one possibility here.  With ant's junit task, you
> can define a custom formatter implementing this interface:
>
>   org.apache.tools.ant.taskdefs.optional.junit.JUnitResultFormatter
>
> That interface has a method endTestSuite that is invoked once at the
> end of all the test cases.  So I can define a customer formatter, and
> in this method, I can check with ConcurrentMergeScheduler and if any
> unhandled exceptions has occurred, I can throw an exception and the
> suite/testcase is marked as failed.  It seems to work.
>
> This is a nice solution in that we don't have to modify every unit
> test to do its own checking.  However, it's not really a "normal" use
> case because formatters are supposed to just "format" the test result
> output.  It also adds a dependence from Lucene's unit test sources to
> ant.  But at least it does work ("progress not perfection").
>
> And objections to this approach?  Is there a better approach?
>
> Mike
>
> "Michael McCandless" <lucene@mikemccandless.com> wrote:
>>
>> "Chris Hostetter" <hossman_lucene@fucit.org> wrote:
>>>
>>> : But it'd be nice to do this across the board, ie, for any junit  
>>> test
>>> : if one of CMS's threads (or, threads launched elsewhere) hits an
>>> : unhandled exception, fail the testcase that's currently running.
>>> : I'll dig and see if there's some central way to do this with  
>>> junit...
>>>
>>> FYI: i did some casual investigation of this and the only thing that
>>> jumped out at me is the static
>>> Thread.setDefaultUncaughtExceptionHandler(...) added in 1.5.  for  
>>> 1.4
>>> there doesn't seem to be a generic way to notice an uncaught  
>>> exception
>>> from any thread.
>>
>> Thanks Hoss.
>>
>> Catching the exception is actually not the hard part because I "own"
>> all the threads spawned by ConcurrentMergeScheduler.  What's  
>> tricky is
>> finding a way to force the currently running JUnit testcase or suite
>> to fail.  I'm digging through JUnit and ant's JUnitTestRunner sources
>> to see if there's some hook somewhere where we could insert a check,
>> just before the suite finishes, to assert that no exceptions were  
>> hit.
>> Or, if I can somehow "look up" the current Test that's running, I
>> could add an error to it.
>>
>> If there are any JUnit and ant experts out there (I'm not!) please
>> chime in!
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message