Path: utzoo!attcan!uunet!mcsun!unido!fauern!tumuc!guug!ecrc!micha
From: micha@ecrc.de (Micha Meier)
Newsgroups: comp.lang.prolog
Subject: Re: error handling (was about arg/3)
Message-ID: <1804@ecrc.de>
Date: 25 Oct 90 10:55:20 GMT
References: <1328@n_kulcscs.kuleuven.ac.be>
Sender: news@ecrc.de
Reply-To: micha@ecrc.de (Micha Meier)
Organization: ECRC
Lines: 44

In article <1328@n_kulcscs.kuleuven.ac.be> bimbart@habakuk.cs.kuleuven.ac.be (Bart Demoen) writes:
>... But still, some error recovery is currently proposed: a goal in error must
>give rise to a replacement of the goal by a call to the builtin predicate
>exit_block/1 with as argument the term error(A,B) where A is an atom identifying
>the type of error (defined by the standard), and B being implementation defined.

I'm still not sure if this approach is better than nothing at all or not.
exit_block/1 can of course be used to catch the error somewhere in the
top-level loop, emit an error message and abort. The question is, why such
a complicated mechanism to get so little? The problem with exit_block/1
is that you have to have a corresponding block/3 call in order to catch it,
and so if you want to something different that just abort, you'd have
to wrap every call you expect may make an error into a block/3.
So, e.g. if you want an undefined procedure to fail, you would write
instead of p(X)

	block(p(X), Something, fail)

in *all* places where p/1 might be undefined. One can hardly imagine
something more awkward. I have discussed this in my NACLP'89 paper
about events.

>  ALL other calls should silently fail if debug is off (the behavior of a Prolog
>  system when debug is on, is not standardized)
>...
>You can have error messages in debug mode - the only mode they make sense in.

As a matter of fact, this is not always true. You can have a 'debugged'
program running in nodebug mode, and with a new set of data your program
does something strange, because some of the builtins just silently failed
instead of making an error. We should not support a programming style
where there are error messages coming in the debug mode, but the user
is happy with them. There are (or should be) always ways to write
your program in such a way that you don't get any error messages
even in debug mode, and then emitting warnings or error messages always
means something significant, even in nodebug mode.
A silent failure is a nightmare.

--Micha
--
E-MAIL  micha@ecrc.de            	MAIL	Micha Meier
						ECRC, Arabellastr. 17
                     				8000 Munich 81
						West Germany