In Knuth's TeX most errors are recoverable. In general when an error occurs the user is dropped into an interactive terminal, and can accept a suggestion for a fallback action to perform. For example, if when parsing an integer in the range [0, 15] the input number is out of bounds, TeX uses 0 instead. The prompt can be avoided entirely using \batchmode in which TeX will always just do the fallback.
This behavior is used in e.g. Overleaf to fully compile TeX documents even if there are errors.
We should replicate this in Texcraft. My idea is to add a new method to TexlangState with the following signature:
Whenever an error occurs this method is invoked. If an error is returned from the method, this error is propagated through the VM like now. If Ok(()) is returned then the fallback code runs.
There is no requirement that the error returned from this method is the name as the error inputted. For example, the handler may have logic to ignore the first N errors.
Finally, the input should probably be a new RecoverableError type that extends the TexError type and contains, in addition, some information on what the fallback code will do ("will use 0 instead").
In Knuth's TeX most errors are recoverable. In general when an error occurs the user is dropped into an interactive terminal, and can accept a suggestion for a fallback action to perform. For example, if when parsing an integer in the range
[0, 15]the input number is out of bounds, TeX uses 0 instead. The prompt can be avoided entirely using\batchmodein which TeX will always just do the fallback.This behavior is used in e.g. Overleaf to fully compile TeX documents even if there are errors.
We should replicate this in Texcraft. My idea is to add a new method to
TexlangStatewith the following signature:Whenever an error occurs this method is invoked. If an error is returned from the method, this error is propagated through the VM like now. If
Ok(())is returned then the fallback code runs.There is no requirement that the error returned from this method is the name as the error inputted. For example, the handler may have logic to ignore the first N errors.
Finally, the input should probably be a new
RecoverableErrortype that extends theTexErrortype and contains, in addition, some information on what the fallback code will do ("will use 0 instead").