You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, fields are constructed without throwing errors. The user calls #validate on each object and catches errors at validation time. Consider refactoring such that fields are validated on construction, and errors are thrown immediately rather than waiting for an explicit #validate call.
This would force users to handle construction-time throws, but I believe this is more intuitive than a silent #new followed by an explicit #validate call.
The text was updated successfully, but these errors were encountered:
I'm rethinking this approach. Considering the high-performance environment in which a FIX engine will likely be run (and given JavaScript's inherent performance shortcomings), try/catch blocks may impose an unnecessary overhead.
Perhaps a #validate pattern is preferred in such a situation. An explicit validation that simply returns a boolean should provide much better performance than try/catch blocks and throws (at the expense of the developer).
Currently, fields are constructed without throwing errors. The user calls #validate on each object and catches errors at validation time. Consider refactoring such that fields are validated on construction, and errors are thrown immediately rather than waiting for an explicit #validate call.
This would force users to handle construction-time throws, but I believe this is more intuitive than a silent #new followed by an explicit #validate call.
The text was updated successfully, but these errors were encountered: