Add try catch block to Safari View Controller logic

[Opstrup]

PR Checklist

• The PR title follows our guidelines: https://github.com/proyecto26/react-native-inappbrowser/blob/master/CONTRIBUTING.md#pull-request-process.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• All existing tests are passing
• Tests for the changes are included

What is the current behavior?

Malformed urls is causing the app to crash since the Safari View Controller does not work with all urls.

What is the new behavior?

Fixes/Implements/Closes #189.

Based on the description okwast gives here a try catch block is added around the initialization of the SFSafariViewController.

With this change exceptions thrown by the native layer can be handled at the react native layer.

[jdnichollsc]

Can we track that exception?

[Opstrup]

Im not sure what you mean by track, could you elaborate? :)

[jdnichollsc]

I was wondering if we can do something similar to this https://github.com/proyecto26/react-native-inappbrowser/blob/develop/android/src/main/java/com/proyecto26/inappbrowser/RNInAppBrowser.java#L167

In order to see the exceptions from Xcode and iOS Console
What do you think? :)

[jamesxabregas]

Any particular reason why this PR hasn't been merged? It fixes a critical bug that crashes the app.

[jdnichollsc]

Did you check my last comment? Please let me know how to do that and I can help you with a new release including that.

Best,
Juan

[jamesxabregas]

I'm not the original author of the pull request, nor an Objective-C developer, although I’ll help as best as I can.

According to this StackOverflow post, this is the way to do it.

NSLog(@"%@",[NSThread callStackSymbols]);

Although, is this something you'd just want to do in React Native DEBUG mode or in production code as well? If it's just going to be printed to the log on the user's device I'm not entirely sure what the value of this would be? The exception has been handled so it wouldn’t seem appropriate to be spitting out exception stack-traces to the logs.

Wouldn't it be better to pass the error back, or a summarised version, to the calling function at the JavaScript layer? At least this way the users of this plugin can handle it appropriately and log it to what every logging mechanism they are using. Some app developers may be using remote logging and/or event logging libraries etc at the Javascript layer.

[jdnichollsc]

@maoapp can you help me reviewing this PR too please? <3

[Rehubbard]

This would be awesome to get merged and released 👍

[jdnichollsc]

Ok, let me do that today :)