>> By monotonicity, I expect that if a query succeeds unconditionally, then a generalization certainly does not fail (otherwise, adding a constraint would increase the set of solutions).

Thank you for clarifying. If I understand correctly you are saying that the success set of a query should increase monotonically with the generality of the query. If so, I don't think that's an unreasonable demand, but I do think it is a bit ideological, given that normal _programs_ are non-monotonic anyway (because negation as finite failure is non-monotonic).

Now, I have to point out that both type-checking and errors are extra-logic features of Prolog (there are no types in first-order logic and of course there are no exceptions). In that sense, it's a bit arbitrary how a predicate "should" be defined. The decision must be made in the context of Prolog, not logic, and the needs of Prolog as a programming language.

In that context, the problem that I see with raising an error on "integer(X)" is that integer/1 is performing a type-check in the context of the datatypes recognised by Prolog. So it makes sense that it should succeed when its argument is of the "integer" datatype and fail if its argument is any other datatype. In this context "X" is not an uninstantiated term, but a term of type "variable", where variable is a Prolog datatype, like "integer".

I think of it as a membership test. If the argument of integer/1 belongs to the set of integers, then the query should succeed. If not, it should fail. A variable is not in the set of integers, so the query should fail.

I also suspect that iterative deepening and, indeed, any kind of nondeterministic program, would be made a lot more complicated if type checks raise errors left and right (a problem you've highlighted with respect to Prolog meta-interpreters and instantiation errors raised by clause/2 in another discussion we had here I think).

Personally I dislike errors: not only are they extra-logical, they force the programmer to add all sorts of boilerplate to her program to handle them and make for code that is harder to read and parse at a glance. The automatically caught exception in Scryer Prolog that you list above is even worse to my mind: it enshrines the boilerplate in the behaviour of the language (if I understand correctly what is being done). So now errors are a first-class citizen of the language. That's awful! I would much prefer a language that helps the programmer identify and eliminate programming errors _before_ the program gets to the point where it has to exit abnormally.