std.unittests/exception Update and Vote

Jonathan M Davis jmdavisProg at gmx.com
Fri Feb 4 07:05:33 PST 2011


Okay, the latest code and documentation is here: http://is.gd/HZQwNz

I've also made the changes in my github fork of Phobos here: 
https://github.com/jmdavis/phobos . So, if this passes the vote, it's just a 
pull request away from being in Phobos.

assertPred, assertThrown, assertNotThrown, and collectExceptionMsg have been 
merged into std.exception and their documentation updated again. There are fewer 
examples now, and hopefully it's more to everyone's liking, though the changes 
aren't drastic. Hopefully, I didn't miss anything that needed changing.

Also, since collectExceptionMsg was catching Throwable and collectException was 
catching Exception, I made them both templated on the type to catch with 
Exception as the default. So, you can use both to catch any Throwable, but they 
default to Exception, so no code should break as a result. I kept Exception in 
their names with the idea that you really shouldn't be catching Throwable or 
Errors except in exception circumstances, so collectException is more correct 
for general use and its name doesn't encourage people to catch the wrong thing 
(it also avoids having to create an alias for backwards compatability).

We're coming up on the time when the proposal has to be voted in or out (Feb 
7th). It looks like Don and/or Walter _may_ make it so that assert is improved 
such that it does some of what assertPred does, printing much better error 
messages, and if that's the case, assertPred will need to be reworked or tossed 
entirely (but whether that happens depends on what they decide between now and 
Feb 7th). So, unless Andrei has a problem with it, I'd ask that you vote for 
assertPred separately from assertThrown, assertNotThrown, and 
collectExceptionMsg. So, if it's decided that assert is going to be improved and 
assertPred won't work as is, at least we can get assertThrown, assertNotThrown, 
and collectExceptionMsg into Phobos (assuming that they pass the vote). If 
assert is improved and assertPred doesn't make it in, and some portion of 
assertPred's other capabilities should still be in Phobos, they can be reworked 
in a future proposal (though if assert doesn't get improved, then they're in 
assertPred as it is).

So, please make any last comments or suggestions on this proposal, and vote on 
whether you think that assertPred should be in Phobos (assuming that assert 
isn't going to be improved such that assertPred isn't necessary) and whether you 
think that assertThrown, assertNotThrown, and collectExceptionMsg should get in 
regardless of whether assertPred does.

- Jonathan M Davis


More information about the Digitalmars-d mailing list