jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: Possible Bug
Date Sat, 14 Dec 2002 21:35:16 GMT
Hi Jason,

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



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?


> -----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
> 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
> the framework runs tearDown. An exception occurs in tearDown (which in
> case is related to the exception in the test), and the tearDown
> 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
> exception was occurring and after capturing it I had a much better
> at
> fixing the problem - and then drew these conclusions about the way
> was acting.
> So, the point is that maybe if the framework catches an exception from
> test, it should ignore exceptions coming from the tearDown call to
> 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:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>

View raw message