Moritz Lenz wrote:
Ben Morrow wrote:

- Presumably when an exception is thrown through a block, the LEAVE and
  POST queues are called (in that order).

POST was inspired from the Design By Contract department, and are meant
to execute assertions on the result. If you leave a block through an
exception you don't have a result, so I don't think running a POST block
makes sense.

OK, if POST is only for asserting on the return value that would make sense. But I thought POST was also supposed to be able to assert that global state had been left as it should, in which case it should be run even on exceptional exit? I'm not sure how any given POST block is supposed to distinguish between an ordinary undef return and an exception, though, to avoid checking the return value. Some sort of guarantee that $! is undef in a POST block unless an exception is currently being thrown might be helpful, but I'm not sure how that interacts with the Perl 6 exception model as a whole.

I'm not sure about running LEAVE blocks either, because that's what
CATCH blocks are for.

LEAVE blocks I am certain *should* be run, no matter how the block is exitted (well, unless a PRE fails: see below). They are equivalent to 'finally' blocks in other languages, and AIUI they are for cleanup: closing files, tearing down database connections and the like.

What if a PRE block fails: is
  the POST queue on the same block called? (Do you have to satisfy your
  post-conditions even if your pre-conditions failed?)

I'd say that if a PRE block fails, nothing else is run (neither LEAVE
nor POST nor ...)

I agree that none of ENTER, LEAVE or the main body of the block should be run. However, if a POST block is asserting, say, that a global holds a valid value, shouldn't that still be checked even if your preconditions failed? I admit I haven't read much about DBC.

- If a POST block is called as a result of a thrown exception, and it
  fails, which exception 'wins'?

Question obsoleted by previous answer ;-)

...maybe :).

- Can a try block catch an exception thrown from its own ENTER or LEAVE
queue?

Yes.

OK. What about PRE/POST? It seems wrong somehow to be able to catch failure of your own pre-/post-conditions: they are meant for the caller to catch. Does that seem right?

Ben

Reply via email to