[Issue 4644] assertExceptionThrown to assert that a particular exception was thrown

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4644



--- Comment #6 from Jonathan M Davis <jmdavisProg at gmail.com> 2010-08-16 01:03:07 PDT ---
Thanks for the help. One thing that I'm finding you need with these types of
functions though is the file and line number. Otherwise, tracking down the
problem can be quite hard. I suppose if the stack trace on linux actually
printed out the functions rather than just their addresses, then it wouldn't be
as big a problem, but as it is, the stack trace is pretty useless. Normally,
I'd tack the file and line number on the end with the default arguments of
__FILE__ and __LINE__, but with the variadic template, I don't think that you
can do that. So, you'd have to be explicit here. In any case, here are my
current versions. They're a bit more concise than yours and work better with
unit tests (given that you shouldn't normally print from unit tests). They're a
bit uglier to use due to the necessity to pass __FILE__ and __LINE__ yourself,
but I think that they work quite well for unit tests at the moment. I see no
need to catch the wrong exception, since it'll just wiz on by and get caught by
the main exception handler like any other exception. The key here is to verify
whether the correct one was thrown. For assertExceptionNotThrown, I would have
printed out the Exception as part of the AssertError that get's thrown, but you
end up with 2 stack traces, and it's ugly. Hopefully, the programmer would have
a fair idea of what Exception would be thrown, and they can go and run the
function without the wrapper if they need to. The function still serves nicely
to indicate test failure however.

void assertExceptionThrown(string file, size_t line, alias E, alias func,
T...)(T args)
    if(__traits(compiles, {try{}catch(E e){}}))
{
    try
        func(args);
    catch(E e)
        return;     // Expected exception was thrown

    throw new AssertError(format("assertExceptionThrown() failed: No %s was
thrown from %s()", E.stringof, __traits(identifier, func)), file, line);
}

void assertExceptionThrown(string msg, string file, size_t line, alias E, alias
func, T...)(T args)
    if(__traits(compiles, {try{}catch(E e){}}))
{
    try
        func(args);
    catch(E e)
        return;     // Expected exception was thrown

    throw new AssertError(format("assertExceptionThrown() failed: No %s was
thrown from %s(): %s", E.stringof, __traits(identifier, func), msg), file,
line);
}

void assertExceptionNotThrown(string file, size_t line, alias E, alias func,
T...)(T args)
    if(__traits(compiles, {try{}catch(E e){}}))
{
    try
        func(args);
    catch(E e)
        throw new AssertError(format("assertExceptionNotThrown() failed: %s was
thrown from %s()", E.stringof, __traits(identifier, func)), file, line);
}

void assertExceptionNotThrown(string msg, string file, size_t line, alias E,
alias func, T...)(T args)
    if(__traits(compiles, {try{}catch(E e){}}))
{
    try
        func(args);
    catch(E e)
        throw new AssertError(format("assertExceptionNotThrown() failed: %s was
thrown from %s(): %s", E.stringof, __traits(identifier, func), msg), file,
line);
}


I really think that we should have more of these types of functions and have
them added to std.exception (or wherever appropriate), so that we can have
better unit testing facilities. assert does the job, but it's not a very
precise instrument. And in this case, it's too verbose due to the necessary
try-catch block.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------