4.15.4.3 Type Errors

A type error occurs when an input argument is of the wrong type. In general, a type is taken to be a class of terms for which there exists a unary type test predicate. Some types are built-in, such as atom/1 and integer/1.

The type of a term is the sort of thing you can tell just by looking at it, without checking to see how big it is. So “integer” is a type, but “non-negative integer” is not, and “atom” is a type, but “atom with 5 letters in its name” and “atom starting with ‘x’” are not.

The point of a type error is that you have obviously passed the wrong sort of argument to a command; perhaps you have switched two arguments, or perhaps you have called the wrong predicate, but it is not a subtle matter of being off by one.

Most built-in predicates check all their input arguments for type errors.

The SICStus_Error term associated with a type error is

type_error(Goal, ArgNo, TypeName, Culprit)

ArgNo

Culprit occurs somewhere in the ArgNoth argument of Goal.

TypeName

says what sort of term was expected; it should be the name of a unary predicate that is true of whatever terms would not provoke a type error.

Culprit

is the actual term being complained about: TypeName(Culprit) should be false.

For example:

| ?- catch((writeq(3),1), Error, true).
Error = error(type_error(callable,(writeq(3),1)),
              type_error(user:(writeq(3),1),0,callable,(writeq(3),1)))