www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Please reply to this to vote to collectExceptionMsg in std.unittests

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Reply here to vote ONLY for the function collectExceptionMsg in Jonathan 
M Davis's std.unittests. Vote closes on Tue Feb 15.

Andrei
Feb 08 2011
next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 2/8/11 4:29 PM, Andrei Alexandrescu wrote:
 Reply here to vote ONLY for the function collectExceptionMsg in Jonathan
 M Davis's std.unittests. Vote closes on Tue Feb 15.
As I stated in the assertNotThrown thread, I don't see any reason why this shouldn't be included if it's helpful for other people, even though I personally didn't feel the need for it so far. Since the main use case seems to be in unit tests to check if the correct exception messages are produced, I'd suggest adding a short note about that to the documentation comment – or is this going to end up in a new std.unittest module anyway? I thought it would be merged into std.exception… David
Feb 08 2011
parent spir <denis.spir gmail.com> writes:
On 02/08/2011 06:29 PM, David Nadlinger wrote:
 On 2/8/11 4:29 PM, Andrei Alexandrescu wrote:
 Reply here to vote ONLY for the function collectExceptionMsg in Jonathan
 M Davis's std.unittests. Vote closes on Tue Feb 15.
As I stated in the assertNotThrown thread, I don't see any reason why this shouldn't be included if it's helpful for other people, even though I personally didn't feel the need for it so far. Since the main use case seems to be in unit tests to check if the correct exception messages are produced, I'd suggest adding a short note about that to the documentation comment – or is this going to end up in a new std.unittest module anyway? I thought it would be merged into std.exception…
This is just one use case reason why me preferred assert idiom has the form assert ( expression, expectation) if expectation is a string --and the outcome isn't one-- then the outcome is to!string'ed. just what you need. Very useful too, in several other cases of outcomes (I mean only when throws, just regular results that are not easily expressible in code). Denis -- _________________ vita es estrany spir.wikidot.com
Feb 08 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:iirnm1$28ig$4 digitalmars.com...
 Reply here to vote ONLY for the function collectExceptionMsg in Jonathan M 
 Davis's std.unittests. Vote closes on Tue Feb 15.

 Andrei
"YES"
Feb 08 2011
prev sibling next sibling parent Tomek =?ISO-8859-2?B?U293afFza2k=?= <just ask.me> writes:
Andrei Alexandrescu napisa=B3:

 Reply here to vote ONLY for the function collectExceptionMsg in Jonathan=
=20
 M Davis's std.unittests. Vote closes on Tue Feb 15.
I'm in two minds. Since Jonathan has improved collectException the proposed= function is just a short-hand for: auto e =3D collectException!MyException(expression); assert (e); assert (e.msg =3D=3D "..."); or: assert (collectException!MyException(expression) =3D=3D new MyException(msg= )); I would use these because of the possibility to test properties other than = .msg. Also, there's an ambiguity "ex.msg is null" vs. "didn't throw". But perhaps msg is important enough to deserve a dedicated wrapper. I'll vo= te in favour, given that the docs are shrunk to something like: Convenience function for extracting the exception's message. Equivalent of: --- auto e =3D collectException(mayThrow); string msg =3D e ? e.msg : null; --- And put a link to collectException. --=20 Tomek
Feb 08 2011
prev sibling next sibling parent Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 Reply here to vote ONLY for the function collectExceptionMsg in Jonathan 
 M Davis's std.unittests. Vote closes on Tue Feb 15.
 
 Andrei
++vote. It's worth noting that the exception chaining (as implemented in the Windows version of the next DMD2) means that it is possible for an exception to have a chain of messages attached to it. I'm not sure if this makes any difference or not -- it *could* be that we also want assert(e.next is null); inside collectExceptionMsg(), to make sure that there were no collateral exceptions. Or maybe we don't care -- but it needs to be mentioned in the docs.
Feb 09 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 08 Feb 2011 10:29:54 -0500, Andrei Alexandrescu wrote:

 Reply here to vote ONLY for the function collectExceptionMsg in Jonathan
 M Davis's std.unittests. Vote closes on Tue Feb 15.
 
 Andrei
Yes
Feb 14 2011
prev sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Andrei Alexandrescu wrote:
 Reply here to vote ONLY for the function collectExceptionMsg in
 Jonathan M Davis's std.unittests. Vote closes on Tue Feb 15.
 
 Andrei
I vote for inclusion. Jens
Feb 14 2011