On 03/09/2012 07:37 PM, H. S. Teoh wrote:
On Fri, Mar 09, 2012 at 07:23:20PM +0100, Timon Gehr wrote:
On 03/09/2012 05:56 PM, Jonathan M Davis wrote:
[...]
It was never intended that AssertError or any other Error be
particularly catchable, but it's also true that D is a systems
programming language, so it'll let you do stuff which is unsafe, so
if you know what you're doing, then there are circumstances where you
can get away with (unit testing is one example of where catching
AssertErrors might make sense). But you have to know what you're
doing, since it's _not_ safe.
- Jonathan M Davis
AssertErrors must be recoverable because of the way contracts work.
Are you referring to contract AssertErrors in unittests, or in general?
In general, I think contracts *should* terminate the program with
extreme prejudice when they fail. It represents assumptions about
internal consistency being broken, which makes it unsafe to do
otherwise.
But in unittests where these assumptions are deliberately broken (to
ensure the contract does what you think it does), it makes sense to be
able to "recover" from AssertErrors.
T
'in' contracts must catch assertion failures because it is enough if one
of them passes.
class Foo{
void foo(int x)in{assert(x==0);}body{}
}
class Bar: Foo{
void foo(int x)in{assert(x==1);}body{}
}
void main(){
Bar bar = new Bar;
bar.foo(0); // ok
bar.foo(1); // ok
}
