Re: Please reply to this to vote to collectExceptionMsg in std.unittests
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
Re: Please reply to this to vote to collectExceptionMsg in std.unittests
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
Re: Please reply to this to vote to collectExceptionMsg in std.unittests
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.
Please reply to this to vote to collectExceptionMsg in std.unittests
Reply here to vote ONLY for the function collectExceptionMsg in Jonathan M Davis's std.unittests. Vote closes on Tue Feb 15. Andrei
Please reply to this to vote to collectExceptionMsg in std.unittests
Reply here to vote ONLY for the function collectExceptionMsg in Jonathan M Davis's std.unittests. Andrei
Re: Please reply to this to vote to collectExceptionMsg in std.unittests
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
Re: Please reply to this to vote to collectExceptionMsg in std.unittests
Andrei Alexandrescu seewebsiteforem...@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
Re: Please reply to this to vote to collectExceptionMsg in std.unittests
Andrei Alexandrescu napisał: Reply here to vote ONLY for the function collectExceptionMsg in Jonathan 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 = collectException!MyException(expression); assert (e); assert (e.msg == ...); or: assert (collectException!MyException(expression) == 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 vote in favour, given that the docs are shrunk to something like: Convenience function for extracting the exception's message. Equivalent of: --- auto e = collectException(mayThrow); string msg = e ? e.msg : null; --- And put a link to collectException. -- Tomek
Re: Please reply to this to vote to collectExceptionMsg in std.unittests
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
