From jan@swi.psy.uva.nl Sat Feb 17 11:43:48 2001
Received: from gollem.swi.psy.uva.nl (root@gollem [145.18.152.30])
	by swi.psy.uva.nl (8.11.2/8.11.2) with ESMTP id f1HAhmZ00285;
	Sat, 17 Feb 2001 11:43:48 +0100 (MET)
Received: (from jan@localhost)
	by gollem.swi.psy.uva.nl (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id LAA22276;
	Sat, 17 Feb 2001 11:43:48 +0100
Date: Sat, 17 Feb 2001 11:43:48 +0100
Message-Id: <200102171043.LAA22276@gollem.swi.psy.uva.nl>
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Subject: Re: [SWIPL] exceptions in PL_call_predicate()
To: Paul Singleton <p.singleton@keele.ac.uk>,
   SWI Prolog <prolog@swi.psy.uva.nl>
In-Reply-To: Paul Singleton's message of Fri, 16 Feb 2001 11:54:56 +0000
Phone: +31 - 20 - 525 6121

> I have a foreign predicate which calls PL_call_predicate(): if I find
> that this call has raised an exception, I want to just fail out of the
> foreign predicate and let Prolog handle the exception.
> 
> Is this safe?  good practice?

There is an option for this:

    PL_Q_PASS_EXCEPTION
         As PL_Q_CATCH_EXCEPTION,  but do  not invalidate the  exception-
         term  while   calling  PL_close_query().      This  option   is
         experimental.

This flag is documented with PL_open_query().  The flags of
PL_call_predicate are the same.  It isn't very experimental any more.

Actually PL_call_predicate is defined as:

int
PL_call_predicate(Module ctx, int flags, predicate_t pred, term_t h0)
{ int rval;

  qid_t qid = PL_open_query(ctx, flags, pred, h0);
  rval = PL_next_solution(qid);
  PL_cut_query(qid);

  return rval;
}

and PL_cut_query() doesn't touch the exception term, so it is safe without
PL_Q_PASS_EXCEPTION as well.  Nevertheless, adding this flag makes it
clear what you are doing and thus more likely it will not only work
today but also next year.

	--- Jan

