Error

There is great wisdom in expecting the unexpected too.

Default subtypes

While some generic errors like syntax issues, invalid imports etc. are raised with the base Error type, some others are subtyped:

• KeyError: the key (name) is not found in scope
• IndexError: index is out of list/text bounds
• CallError: a call is made with insufficient arguments
• TypeError: type mismatch on method call, return, or assign
• AssignError: assigning a new value to an immutable entry
• ValueError: type may be okay, but content is not accepted

Comparisons

Errors always evaluate as falsy:

Error() ? 'is truthy' : 'is falsy'  # is false

Errors are comparable to their type:

Error() == Error  # true

read also about type comparison syntax

A naive way of handling errors could be:

_ <- fat.console
# handling the returned error
maybeFail() <= Error => log('an error has happened')
_                    => log('success')

this only works if option -e / continue on error is set

Although the naive approach may work, it's hard to know where errors will arise. Therefore, the proper way to deal with errors is by setting an error handler using the trapWith method found in the failure library.

See also

• Failure library
• Error prototype extensions