digitalmars.D - Please reply to this to vote to collectExceptionMsg in std.unittests
- Andrei Alexandrescu (3/3) Feb 08 2011 Reply here to vote ONLY for the function collectExceptionMsg in Jonathan...
- David Nadlinger (10/12) Feb 08 2011 As I stated in the assertNotThrown thread, I don't see any reason why
- spir (12/22) Feb 08 2011 This is just one use case reason why me preferred assert idiom has the f...
- Nick Sabalausky (3/6) Feb 08 2011 "YES"
- Tomek =?ISO-8859-2?B?U293afFza2k=?= (22/24) Feb 08 2011 I'm in two minds. Since Jonathan has improved collectException the propo...
- Don (9/13) Feb 09 2011 ++vote.
- Lars T. Kyllingstad (2/6) Feb 14 2011 Yes
- Jens Mueller (3/7) Feb 14 2011 I vote for inclusion.
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
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
On 02/08/2011 06:29 PM, David Nadlinger wrote:On 2/8/11 4:29 PM, Andrei Alexandrescu wrote: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.comReply 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…
Feb 08 2011
"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
Andrei Alexandrescu napisa=B3:Reply here to vote ONLY for the function collectExceptionMsg in Jonathan==20M 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
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
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. AndreiYes
Feb 14 2011
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. AndreiI vote for inclusion. Jens
Feb 14 2011