Possible Bug

["Robertson, Jason" <Ja...@acs-inc.com>]

I'm just going to throw out something I'm seeing, I don't have a fix or any
analysis at this point - just too much to do right now... 

Basically, the problem is that an exception is being buried and not reported
during my Cactus test and that's obviously causing problems in my debugging!


An exception occurs in my test, so control goes back to the framework and
the framework runs tearDown. An exception occurs in tearDown (which in my
case is related to the exception in the test), and the tearDown exception is
the one that gets returned to the client and reported. The "real" exception
is dropped. In my scenario, the exception from tearDown makes no sense which
made it very hard to debug. After a while I figured out where the "real"
exception was occurring and after capturing it I had a much better chance at
fixing the problem - and then drew these conclusions about the way Cactus
was acting.

So, the point is that maybe if the framework catches an exception from a
test, it should ignore exceptions coming from the tearDown call to make sure
that the first exception is the one that is reported to the user.

Thoughts?

Jason

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Possible Bug

[Vincent Massol <vm...@octo.com>]

Hi Jason,

When I coded this part of the framework I wrote the following:

        setUp();

        try
        {
            runServerTest();
        }
        finally
        {
            tearDown();
        }

I chose to do it this way because this is the behaviour of JUnit and I
wanted to have exactly the same behaviour on the server side than junit
has on the client side.

So to answer your question, yes we could change that behaviour but it
would no longer match the junit behaviour (good or bad). Is that a
problem? I don't know...

However, I think Nick is right. We should ask the junit folks what is
their answer to your question. Would you mind sending to the junit list
your question?

Thanks
-Vincent

> -----Original Message-----
> From: Robertson, Jason [mailto:Jason.Robertson@acs-inc.com]
> Sent: 06 December 2002 20:45
> To: 'Cactus Users List'
> Subject: Possible Bug
> 
> I'm just going to throw out something I'm seeing, I don't have a fix
or
> any
> analysis at this point - just too much to do right now...
> 
> Basically, the problem is that an exception is being buried and not
> reported
> during my Cactus test and that's obviously causing problems in my
> debugging!
> 
> 
> An exception occurs in my test, so control goes back to the framework
and
> the framework runs tearDown. An exception occurs in tearDown (which in
my
> case is related to the exception in the test), and the tearDown
exception
> is
> the one that gets returned to the client and reported. The "real"
> exception
> is dropped. In my scenario, the exception from tearDown makes no sense
> which
> made it very hard to debug. After a while I figured out where the
"real"
> exception was occurring and after capturing it I had a much better
chance
> at
> fixing the problem - and then drew these conclusions about the way
Cactus
> was acting.
> 
> So, the point is that maybe if the framework catches an exception from
a
> test, it should ignore exceptions coming from the tearDown call to
make
> sure
> that the first exception is the one that is reported to the user.
> 
> Thoughts?
> 
> Jason
> 
> --
> To unsubscribe, e-mail:   <mailto:cactus-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-user-
> help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Possible Bug

[Nicholas Lesiecki <ni...@eblox.com>]

Hi Jason,

I think this is JUnit's behavior--not Cactus's. It's a good point, and
perhaps worth bringing up on the JUnit mailing list.

Cheers,
Nick

> -----Original Message-----
> From: Robertson, Jason [mailto:Jason.Robertson@acs-inc.com]
> Sent: Friday, December 06, 2002 1:45 PM
> To: 'Cactus Users List'
> Subject: Possible Bug
>
>
> I'm just going to throw out something I'm seeing, I don't have a
> fix or any
> analysis at this point - just too much to do right now...
>
> Basically, the problem is that an exception is being buried and
> not reported
> during my Cactus test and that's obviously causing problems in my
> debugging!
>
>
> An exception occurs in my test, so control goes back to the framework and
> the framework runs tearDown. An exception occurs in tearDown (which in my
> case is related to the exception in the test), and the tearDown
> exception is
> the one that gets returned to the client and reported. The "real"
> exception
> is dropped. In my scenario, the exception from tearDown makes no
> sense which
> made it very hard to debug. After a while I figured out where the "real"
> exception was occurring and after capturing it I had a much
> better chance at
> fixing the problem - and then drew these conclusions about the way Cactus
> was acting.
>
> So, the point is that maybe if the framework catches an exception from a
> test, it should ignore exceptions coming from the tearDown call
> to make sure
> that the first exception is the one that is reported to the user.
>
> Thoughts?
>
> Jason
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>