Quickfix, Is there a "catch-all" method OnMessage to handle incoming messages not handled by overloaded methods?

Question

I use MessageCracker Crack(message, sessionId); within FromAdmin and FromApp (I use version 1.4 of quickfix/n and message cracker seems to also handle admin messages, at least the overloaded OnMessage(Quickfix.Fix44.Longon message, SessionID sessionid){} is handled correctly).

My question is: In case I have not overloaded all OnMessage methods for all incoming messages that go through MessageCracker is there some sort of "catch-all-other" message method that will be called for incoming messages that cannot be forwarded to an overloaded OnMessage method? I do not want to have QuickFix send message rejects just because, for example a FIX server sends an unhandled message which, however, may not be essential to the process flow. I just want to handle it myself. I do not feel comfortable to handle it in try/catch because I do not feel that is the cleanest approach.

Any advice?

Thanks

Answer 1

No, there isn't.

Any respectable FIX counterparty will have a spec that tells you which messages types they will send to you (as well as which fields these messages might contain).

Therefore, you should know all the message types you need to support, and can provide an OnMessage call for each of them.

You could pre-test the message string's type field before calling crack(). That would work, but I think it's misguided.

Answer 2

You can consider the try/catch the cleanest approach.

Internally, the Crack() method simply searches for a method that can handle the received message type (using Reflection). If it can't be found, then a QuickFix.UnsupportedMessageType exception is thrown.

Important: QuickFix won't reject unsupported messages through the MessageCracker, you need to programatically reject it if you want.

When you have a scenario where you don't know all the messages that will be sent by your counterparty I can't see more than these two options:

1. To Catch the UnsupportedMessageType exception and handle the message string by yourself.
2. Not to catch the exception, ignoring it through the OnMessage event