Is there a reason why the snowplow sdk for iOS exception handling is raising/throwing exception which causes app to crash? Why isn’t there a more graceful way in handling such errors? As a client, I don’t want my customers using my app with snowplow to have the app crash just because a context isn’t a self describing json class.
My project is in Swift, is there any plans on the roadmap to convert the iOS sdk to Swift?
This was introduced as a way of ensuring that during development these kinds of bugs would be caught so that when you did push your application live things like malformed contexts and events would not be present. As these would be caught during staging and testing.
One idea could be to introduce a production and development mode to the SDK which would swallow certain exceptions so as to prevent application crashes when the app is in the wild.
For the moment through your best bet for safety would be to:
Wrap each of your event builders inside a try catch block so that you can handle the error yourself
Ensure that your application code is thoroughly tested before pushing to production
I will raise a ticket to explore adding a production mode to the SDK.
I wouldn’t have thought this was a difference between production/dev mode in the code. If I pass in a bad string for the URL, that’s an error regardless of mode.
It’s more that Objective C exceptions are not handled well in Swift. There is, however, automatic translation and handling of errors using an NSError pointer in Objective C that gets translated into a throws in Swift (even though it works a bit differently to a traditional exception).