Re: Consult parse errors are not excpetions?
Jan Wielemaker <[email protected]>
| Newsgroups | gmane.comp.ai.prolog.swi |
|---|---|
| Message-ID | <[email protected]> |
On 01/14/2014 03:09 PM, Edd Barrett wrote: > Hi, > > I originally noticed this when using the C API, but it can also be seen > by using the swipl interactive interpreter. It is probably easier to > explain using the interpreter. > > Look at a normal exception, for example, we call a non-existing > predicate: > > ---8<--- > ?- blah(a), writeln(hi). > ERROR: toplevel: Undefined procedure: blah/1 (DWIM could not correct goal) > ---8<--- > > The predicate blah/1 does not exist, and so an exception fires, thus > preventing the writeln/1 predicate from executing. Fine. > > Now consider a theory file with a syntax error in it -- call it a.pl. > > ---8<--- > ?- consult(a), writeln(hi). > ERROR: /tmp/a.pl:1:11: Syntax error: Unexpected end of file > % a compiled 0.00 sec, 1 clauses > hi > true. > ---8<--- > > A syntax error occurred, but an exception was not thrown. We can see this > is the case since writeln/1 was executed. > > How comes? Should a syntax error not be an exception? There may well be > a good reason for this, but I am curious. Consider an environment where each first error aborts the entire compilation ... > As I said, this can be seen at the C level too. When I use PL_open_query() > followed by PL_next_solution() to initiate 'consult(a)', where a.pl has a > syntax error, I see the syntax error reported on the terminal, but > PL_exception() reports that everything is OK. I have no means by which to > detect the parse error. > > Any thoughts on this behaviour? If you want to know, define user:message_hook/3 to trap the messages and count errors in some global place. Next, you can check these at the end of the consult. Don't try to break out of the consult using exceptions. If you succeed, you'll still break Prolog's administration. The only sensible way to stop at the first error is by calling halt/1, but this terminates the process. Cheers --- Jan > > Thanks >