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 isn’t
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`ArgNo`th 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((write(3),1), Error, true).Error = error(type_error(callable,(write(3),1)), type_error(user:(write(3),1),0,callable,(write(3),1)))

Send feedback on this subject.