Re: Expected Unhandled Exceptions
Wade Barnes <[email protected]> Fri, 11 Jul 2008 14:47:05 -0700
| Newsgroups | gmane.comp.windows.dotnet.nunit.user |
|---|---|
| Message-ID | <[email protected]> |
Hi Charlie, That would do it. Provided the test was not expected to stop prematurely due to the exception as it does with the standard ExpectedException attribute, as the exception is not in the same AppDomain I would not expect it to interrupt execution. Thank-you for our time, Wade ----- Original Message ----- From: Charlie Poole <[email protected]> Date: Friday, July 11, 2008 2:38 pm Subject: Re: [Nunit-users] Expected Unhandled Exceptions To: [email protected] > Hi Wade, > > I suppose half a solution is better than none. :-) > > We could conceivably have an attribute that indicated an > unhandled exception > was expected > and NUnit could look at that attribute for the test that is > running /at the > time/ the exception is > handled. The qualification is that exceptions thrown on a thread > that was > created by some > earlier test would still give an error - but that's what we want > in such a > case. > > Let's suppose the attribute inherited from ExpectedException and > had all the > same properties. > Would that do it for you? > > Charlie > > > _____ > > From: Wade Barnes [mailto:[email protected]] > Sent: Friday, July 11, 2008 2:00 PM > To: Charlie Poole > Cc: 'Wade Barnes'; [email protected] > Subject: Re: RE: [Nunit-users] Expected Unhandled Exceptions > > > > Hi Charlie, > > > > A knotty problem indeed, but a purposeful one. > > > > You assessed the situation correctly, the exception is > originating inside a > child AppDomain on a thread that is isolated inside that > AppDomain. The > code managing the AppDomains in informed of the exception > through the > AppDomain.UnhandledExceptionEvent fired by the AppDomain in > which the > exception occurs. > > > > The exception itself is not so much handled, not sure I would > attempt such a > feat even if I could, it is the code managing the AppDomain that > responds to > the notification that functions correctly; the AppDomain and the > code in it > are gracefully shutdown and queued for later reloading. It > is the response > to the unhandled exception that I am testing. > > > > Nunit correctly and rightly detects the same unhandled > exception. Nunit > also correctly detects that the unhandled exception occurred > during the > particular test. What I am looking for is a way to > decorate the test to > inform Nunit that the unhandled exception it detected during the > test was > expected. > > > > Any thoughts, > > > > Wade Barnes > > > ----- Original Message ----- > From: Charlie Poole <[email protected]> > Date: Friday, July 11, 2008 12:42 pm > Subject: RE: [Nunit-users] Expected Unhandled Exceptions > To: 'Wade Barnes' <[email protected]>, nunit- > [email protected] > > This is a knotty problem and goes a bit beyond what most would > > call unit > > testing. > > > > If I understand rightly, you want to test that > > 1) An exception is thrown, > > 2) That it is caught by the unhandled exception handler. > > > > Since the test is passing, I assume that you are creating a > > thread - or your > > SUT > > is creating one. I say that because it's impoissilbe to have > an > > unhandledexception > > in the test without creating a thread, since NUnit handles all > > exceptions on > > the > > test thread. > > > > I was surprised to hear that the exception was being handled > > correctly by > > your handler, > > since I was under the impression that an unhandled exception > > handler had to > > be > > in the primary appdomain to work. It turns out - as you > probably > > know - that > > MS > > changed that beginning with 2.0. > > > > Per the documentation for AppDomain.UnhandledExceptionEvent, > > your unhandled > > exception should be reported to a handler in the domain where > > the thread was > > created and /also/ to the handler in the primary AppDomain, > > which is created > > by NUnit. > > > > That's exactly what you seem to be seeing. Your handler takes > > care of > > things, > > so the test passes, but NUnit's handler also gets the > exception. > > Since NUnit > > has no way to know that you already took care of the > exception, > > it reports > > it. > > > > Unfortunately, I don't see any way around this, but I'm open > to > > suggestions. > > Charlie > > > > > > > > > > _____ > > > > From: [email protected] > > [mailto:[email protected]] On Behalf > Of > > Wade Barnes > > Sent: Friday, July 11, 2008 9:20 AM > > To: [email protected] > > Subject: [Nunit-users] Expected Unhandled Exceptions > > > > > > > > Hi, > > > > Is there any way to tell a particular test to expect an > > unhandled exception; > > one that would normally be indicated through the > > AppDomain.UnhandledException event? > > > > > > > > I am testing code that uses AppDomains to isolate code. > > One of the tests > > purposely causes an unhandled exception in one of these > > AppDomains to ensure > > it is properly reported and acted upon by the code managing > the > > AppDomains;therefore I am expecting an unhandled exception to > > occur. > > > > The issue: > > > > The test itself passes. > > > > However, > > > > When using the GUI runner the test bar goes Red and the > > unhandled exception > > is reported in the output list. > > > > When using the Console runner this same unhandled exception > > causes the > > runner to return a code of -100; this ends up failing our > > nightly build. > > > > > > > > What I would like to do: > > > > I would like to be able to indicate, for a particular test, > that an > > unhandled exception is expected. I would then expect the > > test to behave > > similarly to any other test expecting an exception; if > received > > it happy > > goes about the remained of its testing business, otherwise it > > fails because > > it did not receive the expected exception. Additionally > > when such a test is > > encountered I would expect the test bar in the GUI not to turn > > Red and the > > unhandled exception not to be reported in the output list; > > similarly I would > > expect the Console runner not to return -100. > > > > > > > > Wade > > > > > > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Nunit-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nunit-users