Snowplow iOS - Exception handling


#1

Hello,

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?


#2

Hi @aechao - no plans to port the SDK to Swift at this time; our priority is adding new functionality to the tracker first.

Will let the SDK’s engineers get back to you on the failure state you cite…


#4

Hey @aechao,

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:

  1. Wrap each of your event builders inside a try catch block so that you can handle the error yourself
  2. 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.

https://github.com/snowplow/snowplow-objc-tracker/issues/307

Thanks,

Josh


#5

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).

Apple’s recommendation is to use errors over exceptions:

Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications

Would you consider a change where the Snowplow iOS SDK moves to errors over exceptions? Or supports both modes for easy consumption from Swift?