Open matkoniecz opened 1 month ago
I see, I'm wondering if there is an easy way to wrap the existing errors (i.e. expose the underlying RequestException to be able to inspect it) or simpls create new exception in this library to cover all? / most? cases. What do you think?
Just read about the "raise Exception(...) from e" pattern, which seems to be a good idea when wrapping exceptions to pass the original exception to the caller.
So maybe I'll add this to all "wrapped exceptions" while still adding the most common errors as it's own exception class.
If I would implement this I would catch multitude of network exceptions, throw new OsmapiNetworkException or similar.
Maybe include original as a field in a new exception?
No idea is it a good design.
basically another aspect of #115 #135
It would be nice to have easy way of distinguishing network failures from other issues.
And yes, recovery is dependent on context - as maybe edit was done and maybe was not done. But ability do detect what happened and being to able to catch specifically network failures would be great.
Currently I would need to catch all
osmapi.errors.ApiError
, cast them to string and try to detect signature comments while hoping for no false positives.