--- Comment #6 from yebblies <> 2011-07-10 21:48:16 EST ---
> Because in general contract violations are errors. There's indeed a special
> case for contracts of overriding functions, but does that justify creating a
> new error type just for that case? I think it's more consistent if all
> contracts throw ContractErrors than if some contracts throw ContractExceptions
> and some other throw AssertErrors.

Only the overridden contracts would throw ContractExceptions, the only way you
would ever see them was if you did:
class A {
  void fun() in { try { assert(0); } catch (ContractException) {} } body {}
class B {
  void fun() in {} body {}

Which is just horrible.

If we disallow scope(exit/failure) and try/catch inside in contracts assert(x)
could be re-written to if (!x) goto contractfail; which bypasses exceptions

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to