One matter which requires getting used to with Marpa is that you are working with BNF, so the core logic is non-procedural. This is why most programmers seem to want to suffer endlessly with recursive descent rather than consider stronger parsers. You can understand recursive descent with purely procedural thinking.
The idea of "do this on error" is procedural thinking. Procedural stuff can be added to Marpa via events, but the programmer needs to bear in mind the engine is being driven descriptively, not procedurally.
One solution to your problem might be rule ranking. See here
. Rule ranking turns Marpa into a better PEG.
The docs I linked are a bit daunting at first glance, or if you don't skim the more technical parts. The basic idea in your case might be to define a "catch all" line as an error case, ranking it below the non-error alternatives.
People working with ranking can find it tricky because the ranking only is applied in very specific circumstances -- the alternatives must be at the same dotted position of a parent rule (which implies they will have the same LHS), the same start position and the same end position. If any of these 3 is not the case, ranking will not be done. This means, for example, that you can't use rule ranking for things which might differ in length. But this seems to be OK in your case. All line alternatives, error or non-error, should start at the same position and end at the same position.
What I think might work is to give the error lines a lower rank than the non-error lines. Then they will be seen only if there is no non-error parse of the line.
The docs contain example and I hope looking at these will help make things clear.
I hope this helps,