www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - throws(statement, ErrorType)

reply spir <denis.spir gmail.com> writes:
How to write a predicate like:
	assert( throws(someStatement, ErrorType) );
?
Meaning a kind of builtin shortcut for:
	try:
	    someStatement;
	    throw new SomeCustomError();
	catch (ErrorType _) {}
that would also have the advantage of beeing usable as assert variant, 
unifying unittest checks. I constantly need that.

Denis
_________________
vita es estrany
spir.wikidot.com
Jan 22 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
spir:


 How to write a predicate like:
 	assert( throws(someStatement, ErrorType) );


Are you using Design By Contract a lot? Contracts need to contain asserts
only...

Bye,
bearophile
Jan 23 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 23 January 2011 00:47:13 bearophile wrote:

 spir:

 How to write a predicate like:
 	assert( throws(someStatement, ErrorType) );


 
 Are you using Design By Contract a lot? Contracts need to contain asserts
 only...


Not necessarily. In fact, in general, the tact that has been taken with Phobos 
is that you use assertions when you're verifying that Phobos is correct, and
you 
use enforce (or an if-statement which throws an exception) when verifying that 
arguments given by outside code is correct.

Design By Contract itself says _nothing_ about verifying that a contract is 
being followed by not. You could use DbC and _never_ check it, making it 
undefined behavior when a contract is violated. After all, DbC says that the 
caller _will_ give the function arguments which follow the contract, so if you 
don't _have_ to check anything. Obviously, if you want more robust code, you 
actually verify that arguments are per the contract, but you don't _have_ to.

In general, I think that an API should throw an exception if bad arguments are 
given, not use an assertion. The assertion is _useless_ when dealing with a 
public API once it's in a library (except if the function is templated), since 
the assertion will already have been compiled out (assuming that you're dealing 
with a release build, but that's the most likely case). Using assertions to 
verify that your own code is internally consistent is great, but it's not so 
great when you have to deal with 3rd parties.

Regardless, from this post and previous posts that you have made, I get the 
impression that you're mixing up the concept of Design by Contract and a
typical 
implementation of it. All that DbC says is that the arguments that a caller 
gives a function must meet certain requirements and that if they do, the result 
of the function will meet certain requirements. Verifying that the contract is 
kept has nothing to do with DbC. It's just good practice if you want to
minimize 
bugs.

- Jonathan M Davis
Jan 23 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


Not necessarily. In fact, in general, the tact that has been taken with Phobos
is that you use assertions when you're verifying that Phobos is correct, and
you use enforce (or an if-statement which throws an exception) when verifying
that arguments given by outside code is correct.<


Phobos is using enforce mostly as a temporary work-around of the fact that the
DMD compiler is not able to automatically switch using a debug version of
Phobos or a release version of it when you compile your code in notrelase or
relasee mode, so currently contract assertions are vanished unless you are
using a template.

Maybe some enforce() will be left in Phobos, but currently they 1) slow down
code, 2) kill inlining, 2) there's no way to disable them, 4) turn nothrow
functions into throw ones even if there is no need for this in their algorithm,
so most of those enforces() will need to be killed from Phobos.



All that DbC says is that the arguments that a caller gives a function must
meet certain requirements and that if they do, the result of the function will
meet certain requirements. Verifying that the contract is kept has nothing to
do with DbC. It's just good practice if you want to minimize bugs.<


I don't believe this :-)

Bye,
bearophile
Jan 23 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 23 January 2011 09:24:25 bearophile wrote:

 Jonathan M Davis:

Not necessarily. In fact, in general, the tact that has been taken with
Phobos is that you use assertions when you're verifying that Phobos is
correct, and you use enforce (or an if-statement which throws an
exception) when verifying that arguments given by outside code is
correct.<


 
 Phobos is using enforce mostly as a temporary work-around of the fact that
 the DMD compiler is not able to automatically switch using a debug version
 of Phobos or a release version of it when you compile your code in
 notrelase or relasee mode, so currently contract assertions are vanished
 unless you are using a template.
 
 Maybe some enforce() will be left in Phobos, but currently they 1) slow
 down code, 2) kill inlining, 2) there's no way to disable them, 4) turn
 nothrow functions into throw ones even if there is no need for this in
 their algorithm, so most of those enforces() will need to be killed from
 Phobos.


enforce is _not_ going away. What _has_ been discussed is having a non-lazy 
version of enforce for cases where we don't need a lazy version (but it still 
wouldn't be the default - if nothing else because that would change the
behavior 
of code). There has also been some discussion of making the compiler smart 
enough to see that a particular paramater doesn't need to be lazy and make it 
non-lazy if that's the case (allowing you to use enforce both lazily and non-
lazily).

And there are plenty of functions in Phobos which _should_ be throwing. I 
actually don't expect that there are all that many functions in Phobos which
are 
throwing which shouldn't be (though I'd have to check). I'd expect that there 
_are_ plenty however that could be made nothrow which haven't been (though we'd 
need a conditional nothrow of sorts for templates just like we need for pure if 
we want that to really work), but there are also plenty which _should_ be 
throwing. std.datetime throws quite a bit - typically on bad arguments - and it 
_should_. However, every function in there that can be marked as nothrow is.


All that DbC says is that the arguments that a caller gives a function
must meet certain requirements and that if they do, the result of the
function will meet certain requirements. Verifying that the contract is
kept has nothing to do with DbC. It's just good practice if you want to
minimize bugs.<


 
 I don't believe this :-)


Well, believe what you like, but if you argue that DbC _requires_ that 
assertions be used, you're going to get people arguing with you.

- Jonathan M Davis
Jan 23 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/23/2011 09:47 AM, bearophile wrote:

 spir:


 How to write a predicate like:
 	assert( throws(someStatement, ErrorType) );


 Are you using Design By Contract a lot? Contracts need to contain asserts
only...

 Bye,
 bearophile


No, not yet. I don't see your point.

Denis
_________________
vita es estrany
spir.wikidot.com
Jan 23 2011