On Sunday 30 January 2011 04:13:59 Jens Mueller wrote: > Masahiro Nakagawa wrote: > > I vote Andrei's suggestion, std.exception is better than new > > std.unittests. I think testing module should provide more features(e.g. > > Mock, Stub...). Your helpers help assert writing style but not help > > testing. > > In addition, std.exception already defined similar functions. > > I do not like putting it in std.exception. Maybe the name std.unittest > is also not good. I would propose std.assert if assert wasn't a keyword. > When I use std.exception I want to handle situations that are part of > the spec (i.e. exceptions) whereas Jonathan's module helps me writing > asserts (that's most of the time unittests). > Basically it helps me verifying behavior according to a spec. I want to > keep the dichotomy of errors and exceptions. Putting both things in one > module is rather strange to me. What are the arguments for putting it in > std.exception? I find the size a rather weak argument. I thought about > providing an assertDeath ones std.process is redone. > And even though enforce and assert are mirroring each other they are > used in different contexts. I would _not_ expect helpers for writing > assertions (Assert_Error_) in a module named std.exception.
Would you expect assumeUnique or pointsTo to be in std.exception? I sure wouldn't, but for whatever reason, they're there. std.exception is a bit of a an odd module anyway. enforce and collectException are the only two which are exception related, and there aren't many functions in there at all. collectExceptionMsg, which is one of my proposed functions, definitely belongs in std.exception, since it's similar to collectException. The others are more debatable. They all throw AssertErrors on failure, and two of them - assertThrown and assertNotThrown - test for exceptions, but they aren't really exception-related overall. However, std.exception is by far the best fit of the currently existing modules, and enforce is essentially an assert that throws an exception instead of an AssertError, and it's in std.exception. So, yeah. It's a bit odd to stick them in std.exception, but std.exception is already rather odd, and if we don't want to create a new module, it's by far the best place to put them. And unless we forsee added a bunch of new unit testing functions to Phobos, creating a new std.unittests would mean having a pretty small module. Ignoring overloads, std.unittests would have only 4 functions in it. And if we put collectExceptionMsg in std.exception where it belongs, then std.unittests would have only 3 functions. And unless we really expect a bunch of new unit testing functions, that really doesn't seem like a good idea to me. And virtually every unit testing function that I've come up with has been merged into assertPred. So, don't forsee there being much in the way of additions to std.unittests unless someone comes up with something drastically different which makes it into Phobos. So, while I don't think that std.exception is a great fit, I do think that it's a reasonable fit. If anything, I think that it would be better to come up with a better name for std.exception than it would be to stick my new functions in a separate module. But we _already_ rename std.contracts to std.exception, so that would mean renaming that module _again_, and I have no idea what a better name would be anyway. - Jonathan M Davis