Path: utzoo!utgpu!watserv1!watmath!att!att!dptg!ulysses!andante!alice!pereira
From: pereira@alice.att.com (Fernando Pereira)
Newsgroups: comp.lang.prolog
Subject: Re: error handling (was about arg/3)
Message-ID: <11521@alice.att.com>
Date: 22 Oct 90 21:07:14 GMT
References: <1328@n_kulcscs.kuleuven.ac.be>
Reply-To: pereira@alice.UUCP ()
Organization: AT&T, Bell Labs
Lines: 30

In article <1328@n_kulcscs.kuleuven.ac.be> bimbart@habakuk.cs.kuleuven.ac.be (Bart Demoen) writes:
>Following the discussion on arg/3 ...
>
>  The standard should specify how a builtin predicate can be called 'correctly'
>  and the effect of such calls (most 'correct' calls succeed, but there is nothing
>  against deciding that calling arg/3 with a negative first argument is not an
>  error and defining the behaviour as fail)
>  ALL other calls should silently fail if debug is off (the behavior of a Prolog
>  system when debug is on, is not standardized)
>
>This is sensible for running applications - they typically have debug off ...

I strongly disagree with this. Running applications *do* have bugs, and silent
failure will make those bugs extremely difficult to report. Silent failure
is *never* a reasonable response to an error situation, not withstanding
the sloppiness in that regard of most Prolog systems (including some
I had something to do with...). The reasonable response is to raise an
exception. Such exceptions might be caught by handlers that then proceed
to fail silently, but by default uncaught exceptions will arrive back
at some top level and be reported. That way, bugs that cause builtins to be
called with incorrect arguments will produce error reports directly related
to source of the problem.

Fernando Pereira
2D-447, AT&T Bell Laboratories
600 Mountain Ave, Murray Hill, NJ 07974
pereira@research.att.com