As discussed in the mapping procedures, we treat error alternatives the same as regular alternatives. It is up to the user to recognize that the error alternative was matched. However, the 3GPP specifications often specify error alternatives in ways that don't seem useful. Let's consider some examples.

                { 1 ! < Ignore : bit = < no string >> }

In this example, a send construction is being used in the error alternative. This seems pointless, because presumably an encoder would not encode an error alternative and therefore would not encode whatever the send construction specifies for the encoding. Remove the send construction in such cases. In the rest of the examples, we'll omit the send construction.

Next, observe the meaning of this alternation: a one bit is accepted and a zero bit is an error. In this case, you could just as well replace the alternation with the good alternative. A decoder will fail on bad input. If, however, you want to be able to tell that decoding failed for this reason, you can replace the alternation with "bit" and write your code to report an appropriate error if the bit is zero.

                ! < PDCH pairs configuration error : { 1 1 } { bit (*) > }

In this example, the error alternative is a never-ending bit string. This is pretty useless for a decoder, as it doesn't allow the decoder to recover and continue decoding the rest of the data. You have two options in this case. First, you could entirely remove the error alternative. This will cause the decoder to fail if that input would have been matched. Second, you could modify the error alternative to be simply the determinant (the "{11}"). In that case, if the error alternative is found, the decoder may or may not fail, depending on the input, but your code can report an error if the error alternative was matched.