ResendRequest (silently) aborted when one of the message to resend was (sent and) stored with a bad checksum

When a bug of the application around QuickFIX/J causes the generation of a message containing non-ISO-8859-1 characters (e.g. a price set to NaN or Infinity will be formatted to a special character by java.text.DecimalFormat), the computed checksum is wrong (checksum is computed on Unicode characters, before they are converted to bytes, and non-ISO-8859-1 characters will be replaced by '?' during the chars to bytes conversion, making the checksum inconsistent).
The peer FIX application will detect the problem and skip the affected message, then it will send a ResendRequest.

To handle the ResendRequest, QuickFIX/J will retrieve asked messages in bytes version, will convert them to chars (still containing '?' instead of non-ISO-8859-1 characters), then parse them (and hopefully resend them).
When parsing the message, QuickFIX/J detects the invalid checksum and throws an InvalidMessage exception.
The problem is that this exception is not caught when iterating over the messages to parse, but in the next(Message message) method, as if the error was in the ResendRequest message.

The consequence is that following messages are never sent (and that no SequenceReset message is sent for the peer FIX application to skip the erroneous message).