Open cosama opened 5 years ago
The ExtrapolationException could be extended to have subclasses for future or past. Though we need to be careful as sometimes data is inconsistent and some transform data could be in the future and some in the past if the transform requested spans multiple links. So there would probalby need to be a third type.
As an intermediate workaround you could use _getLatestCommonTime
and compare your queried timestamp as a first order heuristic. It's a backwards compatibility API that's not recommended, but if you plan to migrate to more expressive exceptions it would be fine to use in the intermediate timeframe.
getLatestCommonTime
was exactly what I was looking for. I literally spend hours digging through the code and didn't see that one. Thanks for pointing that out.
I used the return_debug_tuble=True
flag and filtered the error message. That seemed to work too, but as I said probably not optimal either.
I have an application, where I might have some initial lookups that would require extrapolation to the past. These lookups could just be ignored and the program should move on to the next value to look up. However, subsequent lookups should wait until the transform is available (if an extrapolation to the future would be required).
I don't really see a way of achieving such a behavior in
python
, except for maybe using acan_transform call
with thereturn_debug_tuple=True
flag and then parsing the message. Seems not a really good way of getting this done.In C++ I could probably use a
message_filter
, however, these are not available inpython
(if you ask mepython
thus is still not really a first-class-citizen).Is there any other way of doing this, or can we add a mechanism that gives finer control over
ExtrapolationException
?