-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Exceptions #12
Comments
When receiving messages via a socket connection, it's common to receive partial messages when under load. As these partial messages are appended to the reassembly buffer (using So the recommended structure is to call I thought this was better than returning, eg. That said, I'm playing with extensions to What's your use-case? Why is an exception the best solution for you? What exception would you expect? |
I'm not in a real case scenario, i have already work with a big project with FIX, but in java. ` if len(self.pairs) == 0:
|
There is an interesting slippery slope here: the goal of a simple FIX library is to avoid some of the complexity of using, eg. QuickFIX. Once you start down the route of checking for tag 8 at the start, you end up then wanting to check tag 9 is next, and then tag 35, and then ... pretty soon you end up validating messages against a full spec/schema. That said, the only way I currently check for message boundaries is tag 10, so ... there's at least a toe on that slope already. I will think some more about this. In the meantime, you should know that a returned |
Hum, i understand you and recognize the merits of your view. |
If you don't mind, I'd like to leave this open while I think some more. I'll update it once I've got a tentative plan, and see what you think. |
Ok, here's my plan:
This setting will enable more detailed error detection and reporting, using a suitable set of I expect I'll have this done within a week or so. |
There is some reason to return null instead of raising exceptions in parser.get_message ?
The text was updated successfully, but these errors were encountered: