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. Some are defined in library(types), such as chars/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 exception code 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.

Some TypeNames recognized by the system include:

• 0 -- No type name specified
• atom
• atomic
• callable
• db_reference
• integer
• number

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)
     

true 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