std.unittests/exception Update and Vote

Jens Mueller jens.k.mueller at gmx.de
Sun Feb 6 14:13:25 PST 2011


Jonathan M Davis wrote:
> 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.

I vote for inclusion of assertThrown and assertNotThrown.
BTW will an improved built-in assert support something like
assert(notThrown(expression)) with a good error message?

collectExceptionMsg may seem too simple and not useful. But I think it
should be included because I don't see how to write a good one-liner
using collectException for the equivalent of
assert(collectExceptionMsg(myExpression) == "MyMessage");
That's why I think it should be included as well.

collectExceptionMsg's implementation may be changed using
collectException like this (untested code):

auto result = collectException!(E)(expression());
if (result is null) return cast(string)null;
else                return result.msg;

But that can be done at a later point.

I'm a bit unhappy with how std.unittests ended. I understand that having
a better assert in the language itself is much preferred. Because only
this way one can make sure that it works properly with contracts. On
bright side Jonathan proposing better assertions started this whole
process and this is very important to me. Thank you very much.
I also vote for inclusion of assertPred. Maybe one can make it
deprecated even though it's a bit strange. And once the new built-in
assert is ready replace assertPred's code to give a good message
describing how to migrate. I'm in favor of improved assertions even
though they will be replaced later. Because I cannot foresee when the
new built-in assert will be available.

Jens


More information about the Digitalmars-d mailing list