Re: Failing on event occurence

From: Loizos Michael <>
Date: Sat 03 Nov 2001 12:46:02 PM GMT
Message-Id: <>
Thanks Kish,

that will do fine. Here is the way to do it in order to have different
behaviors according to whether the Goal succeeded, failed or was interrupted: 

 block(run_goal(Goal), too_long, goal_stopped),
 continue, ...

 event_after(too_long, 100),
 once(((Goal, goal_succeeded) ; goal_failed)),

and define the predicates goal_stopped, goal_succeeded and goal_failed
accordingly. In any case the execution will continue normally after the block
command (except in the case goal_stopped fails.


At 05:40 μμ 2/11/2001 +0000, Kish Shen wrote:
>>I need some help on the following issue. I have a piece of code like:
>>  set_event_handler(too_long, stop_execution/0),
>>  event_after(too_long, 100),
>>  compute,
>>  cancel_after_event(too_long).
>I assume you defined stop_execution/0 to fail, and this did not cause
>compute/0 to fail? The manual probably should be clearer, but any failures
>inside the after event handler goal is not propagated. This allows all
>pending after events to be handled.
>In order to cause a failure in the `outer' computation, the handler should
>not fail directly, but set up and trigger another goal that is executed
>which does cause the failure. The simplest way to do this is to wrap your
>compute/0 in a block/3:
>  start :-
>        set_event_handler(too_long, exit_block/1),
>        event_after(too_long, 100),
>        block(compute, too_long, fail),
>        cancel_after_event(too_long).
>Note that if compute/0 fails on its own, the after event is not turned
>off. For a more elaborate example, take a look at the timeout/4 example at
>the end of the Events and Interrupts chapter of the User Manual.
>Kish Shen

Loizos Michael (
Received on Sat Nov 03 12:47:53 2001

This archive was generated by hypermail 2.1.8 : Wed 16 Nov 2005 06:07:11 PM GMT GMT