--- Comment #4 from yebblies <> 2011-07-10 20:47:00 EST ---
(In reply to comment #3)
> A simple fix for this would be to add a flag for compiler-generated catch
> blocks that'd allow bypassing @safe checks when appropriate. I wonder how it
> works for scope(failure)...
Simple, yes.  But is it correct?  The whole idea is that Errors can leave the
program in an invalid state, so continuing after one in @safe code is not
allowed.  If there's no chance of leaving the program in an invalid state, why
is it an error in the first place?

> And yes OutOfMemoryError shouldn't be caught by contracts. Adding a new
> exception type would help, but I think ContractException should be
> ContractError instead and be a subclass of Error.

Why would it be an Error?  An in contract failure is allowed, it just means
that a different in contract in the hierarchy should be tried instead.  The
meaning of assert inside in contracts is very different from asserts everywhere
else, where they mean they program has reached a state that shouldn't be
possible.  I think out contracts should throw normal AssertErrors though.

I'm starting to think assertions inside in contracts (for virtual functions
only) should become special contractAssert()s throwing ContractExceptions.

Regardless of the correct fix, is this a blocker for you?  It might be worth
jamming in a workaround before the release is done if it is.

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

Reply via email to