Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers

Webmaster Forum / Perl / General Perl Topics / July 2009



Tip: Looking for answers? Try searching our database.

Clarification of S04 closure traits

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Ben Morrow - 25 Jul 2009 21:39 GMT
I'm iworking on a patch for Perl 5 that implements the Perl 6 closure
traits (ENTER/LEAVE/...) as special blocks. There are several details
that aren't clear to me from either S04 or the spec tests; I apologize
if these have been discussed before, as I haven't been following p6l.
I'm also not subscribed, so if people could keep me in the CC that would
be appreciated.

- Presumably when an exception is thrown through a block, the LEAVE and
 POST queues are called (in that order). 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?)

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

- Presumably if an ENTER block dies, the rest of that ENTER queue is
 abandoned. Does that also apply to the LEAVE queue? What should

   {
       LEAVE { say "leave1" }
       LEAVE { say "leave2"; die "foo"; }
   }

 print? Similarly POST: once one post-condition has failed, are
 subsequent post-conditions checked?

- Can a try block catch an exception thrown from its own ENTER or LEAVE
 queue? For example in this case:

   try {

       try {
           ENTER { die "foo" }
           CATCH { default { say "caught inside" } }
       }

       CATCH { default { say "caught outside" } }
   }

 which CATCH block gets the exception? What about PRE/POST: can you
 CATCH failure of your own pre-/post-conditions?

- Does it make any difference in any of the above if 'die' is replaced
 by 'exit'?

Ben
Moritz Lenz - 26 Jul 2009 13:42 GMT
> I'm iworking on a patch for Perl 5 that implements the Perl 6 closure
> traits (ENTER/LEAVE/...) as special blocks. There are several details
> that aren't clear to me from either S04 or the spec tests; I apologize
> if these have been discussed before, as I haven't been following p6l.

No need to apologize; such things should be clear from reading the spec.

Note that my answers are in no way authoritative, just proposals on how
to handle it (and maybe starting point of useful discussions).

> I'm also not subscribed, so if people could keep me in the CC that would
> be appreciated.
>
> - 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.
I'm not sure about running LEAVE blocks either, because that's what
CATCH blocks are for.

> 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 ...)

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

Question obsoleted by previous answer ;-)

> - Presumably if an ENTER block dies, the rest of that ENTER queue is
>   abandoned. Does that also apply to the LEAVE queue? What should
[quoted text clipped - 6 lines]
>   print? Similarly POST: once one post-condition has failed, are
>   subsequent post-conditions checked?

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

Yes.

> For example in this case:
>
[quoted text clipped - 13 lines]
> - Does it make any difference in any of the above if 'die' is replaced
>   by 'exit'?

No idea, really.

HTH,
Moritz
Ben Morrow - 27 Jul 2009 17:27 GMT
>> - Presumably when an exception is thrown through a block, the LEAVE and
>>   POST queues are called (in that order).
[quoted text clipped - 3 lines]
> 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
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2010 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.