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
{{ message }}
This repository has been archived by the owner on Mar 14, 2024. It is now read-only.
would produce, according to my contract and my code, the following log:
Error 162, reqId 65121: Historical Market Data Service error message:No historical market data for EUR/CASH@FXSUBPIP Last 300, contract: Contract(secType='CASH', conId=12087792, symbol='EUR', exchange='IDEALPRO', currency='USD', localSymbol='EUR.USD', tradingClass='EUR.USD')
And an empty "bars" list returned.
To work around this issue (the blindness of a developer on errors) I wrote a small decorator to speculate over the input argument and catch some errors:
But is tricky to maintain it and it's definitely smelly.
Also, we can have the requestId as a better hook and be clear on the error source without speculating over the errors array in search of a relevant one.
IMHO the best way to handle this would be using a dedicated object and return, at any request, all the data regarding the response received (an errors field, the request id, the response data which may be empty, and so on), but I think that would be hard to switch all the calls to this new behaviour, so my proposal is just to raise exceptions regarding errors.
Having the request id in your hand would make this easy.
To avoid breaking changes on previously releases, you may add an argument in the IB object constructor to raise or not exceptions on methods, that may have a false default.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hello. AFAIK Ib Insync methods doesn't raise errors, let me explain better:
A call like this one:
would produce, according to my contract and my code, the following log:
And an empty "bars" list returned.
To work around this issue (the blindness of a developer on errors) I wrote a small decorator to speculate over the input argument and catch some errors:
But is tricky to maintain it and it's definitely smelly.
Also, we can have the requestId as a better hook and be clear on the error source without speculating over the errors array in search of a relevant one.
IMHO the best way to handle this would be using a dedicated object and return, at any request, all the data regarding the response received (an errors field, the request id, the response data which may be empty, and so on), but I think that would be hard to switch all the calls to this new behaviour, so my proposal is just to raise exceptions regarding errors.
Having the request id in your hand would make this easy.
To avoid breaking changes on previously releases, you may add an argument in the
IB
object constructor to raise or not exceptions on methods, that may have afalse
default.The text was updated successfully, but these errors were encountered: