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.

See the definitions in the error prototype extensions.


Errors can also be declared explicitly; you must use the type constructor:

_ <- fat.type.Error

Error('an error has ocurred')  # raises a generic error

MyMistake = Error
MyMistake('another error has ocurred')  # raises a MyMistake subtype error


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

Another naive way to deal with errors, but one that always works, is to use a default operation:

maybeFail() ?? log('an error occurred')

Although the naive approach may work, the proper way to deal with errors is by setting an error handler using the trapWith method found in the failure library.

See also

results matching ""

    No results matching ""