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
This is mostly about how to treat exceptions, we are currently using a third party geo localization package. Sometimes requests might fail, and in that case an uncaught exception will be fired, which is not something good.
It will make somewhat a cool improvement if we get to look at the places where uncaught exceptions are and provide fallback methods; for example in case of failure of a [localization] request, the search will be made in an offline database that can be downloaded via a custom artisan command.
The text was updated successfully, but these errors were encountered:
What do you think the behaviour should be if the underlying geo api fails?
I have already mentioned one behavior to consider in this part:
for example in case of failure of a [localization] request, the search will be made in an offline database that can be downloaded via a custom artisan command.
Of course, this should not be limited to the solution that i have proposed, there is always a room for creativity.
This is mostly about how to treat exceptions, we are currently using a third party geo localization package. Sometimes requests might fail, and in that case an uncaught exception will be fired, which is not something good.
It will make somewhat a cool improvement if we get to look at the places where uncaught exceptions are and provide fallback methods; for example in case of failure of a [localization] request, the search will be made in an offline database that can be downloaded via a custom artisan command.
The text was updated successfully, but these errors were encountered: