www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.unittests/exception Update and Vote

reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Feb 04 2011
next sibling parent Don <nospam nospam.com> writes:
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.
 
 - Jonathan M Davis


Yes for assertThrown and assertNotThrown. Ambivalent about 
collectExceptionMsg.
I strongly believe that assertPred should not be included. But I think 
it can be done properly. Please make a bugzilla request for the 
improvements to assert().
Feb 05 2011
prev sibling next sibling parent David Nadlinger <see klickverbot.at> writes:
On 2/4/11 4:05 PM, Jonathan M Davis wrote:

 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 think the topic has already been discussed quite exhaustive, so I'll 
just list my votes: Strong yes for assertThrown (I have something like 
that in all of my D1/D2 projects), rather ambivalent regarding 
assertNotThrown and collectExceptionMsg, and a definite no to assertPred 
– we can do better than that!

David
Feb 05 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.1276.1296831944.4748.digitalmars-d puremagic.com...

 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'm in favor of all of them.

Sure, maybe we could do better than assertPred, but when's that actually 
going to happen? In the meantime, assertPred is a hell of an improvement 
over the current state and it exists *now*. I don't want to needlessly 
hijack the present just for the sake of some still-hypothetical future.
Feb 05 2011