TFM is very thorough in the checks it performs while reading TFM data, to the point that it could probably be used as a validation tool. Every compliance problem detected will be signalled with a warning or an error, depending on the seriousness of the problem (in fact, only one compliance condition is a warning currently; all others being errors). At the same time, TFM also tries to offer a way out of problematic situations (in the form of restarts, currently non-interactive), when it sounds reasonable. This means that it is almost always possible to load a font, however broken it may be.
When loading a file, a restart named
cancel-loading is always
active. If invoked,
load-font will just abort and return
Otherwise, the available restarts depend on the dynamic context and the
particular condition being signalled. The following graph depicts the
conditions / restarts ontology related to compliance problems. Green squares denote warnings, red ones denote errors, and blue
ellipses denote restarts. By following a branch from left to right in
this graph, you get an idea of which restarts are available when a
specific condition is signalled. They are ordered by decreasing
proximity to the signalling code (or, to put it differently, by
increasing level of abstraction). The conditions in this graph are
described precisely in Exported conditions in The TFM Reference Manual. The restarts, on
the other hand, are not, but their names should be self-explanatory.
Note that a branch in this graph does not necessarily correspond to a
specific code path in the library. Different code paths may have
different restarts with the same name when it makes sense, but eponymous
restarts are “merged” into a single node in the graph.