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, suppose we had a predicate

date_plus(NumberOfDays,Date0,Date)

which held when `Date0` and `Date` were `date(`

`Y``,`

`M``,`

`D``)`

records and `NumberOfDays` was
the number of days between those two dates. You might see an error
term such as

type_error(/* Goal */ date_plus(27, date(18,mar,11), _235), /* Argno */ 2, /* TypeName */ integer, /* Culprit */ mar

Send feedback on this subject.