Depending on the support of async queries by the driver, exceptions during query time are handled differently:
in _exec_synchronous_queries, the only exception being caught is MsticpyDataQueryError, anything else is directly raised to the user.
on the other hand, in _exec_queries_threaded,
we have a blanket try/catch exception and a retry mechanism
What I would suggest is to add a parameter to decide how exceptions should be handled.
Similarly to what is being done in pandas when trying to convert data types:
- "coerce" to catch MsticpyDataQueryError, log it and return the (truncated) result of the queries that worked
- "raise" to raise all exceptions
This would assume that all drivers properly handle exceptions and raise MsticpyDataQueryError. It may not be the case today, but I think it would make sense nonetheless
For retry, I would be tempted to remove it and leave its implementation up to the driver.
I can work on that PR if we agree on the right way forward :)
Depending on the support of async queries by the driver, exceptions during query time are handled differently:
in _exec_synchronous_queries, the only exception being caught is MsticpyDataQueryError, anything else is directly raised to the user.
on the other hand, in _exec_queries_threaded,
we have a blanket try/catch exception and a retry mechanism
What I would suggest is to add a parameter to decide how exceptions should be handled.
Similarly to what is being done in pandas when trying to convert data types:
This would assume that all drivers properly handle exceptions and raise MsticpyDataQueryError. It may not be the case today, but I think it would make sense nonetheless
For retry, I would be tempted to remove it and leave its implementation up to the driver.
I can work on that PR if we agree on the right way forward :)