Remove fatalError in throwing function to bubble error up and let caller handle the situation

[jakobmygind]

No description provided.

[mariusc]

Hey Jakob! Can you point this PR to the feature/spm-support branch, please?

The issue you're fixing there is something we've seen often, and is usually a sign of something else that went wrong. It was a fatalError on purpose, because if it gets in that situation, then there's probably something else that has gone wrong. We have talked a few times about making it into a try. Let me just try and get the others involved in the review too 😄

[jakobmygind]

@mariusc My bad, somehow forgot to point to the spm-branch 🙈 The reason for this PR is that the function in question is a throwing one, but the only throwing thing in the scope results in a fatalError, which doesn't make a lot of sense. Also there seems to be some issues having the SDK in a different module than the main one, especially running the app for the very first time, and if this method fatalErrors then there's no way the missing translations can be handled gracefully manually in these special cases. If it were to fatalError here, then it should be guaranteed that if the internal function throws there's absolutely no way the app will work. With the throwing function actually throwing I am now able to safeguard like this:

internal var lo: Localizations {
    guard let manager = NStack.sharedInstance.localizationManager else {
        return Localizations()
    }
    do {
        return try manager.localization()
    } catch {
        print("saved translations not found due to \(error), falling back to bundled json")
        return loadTranslationsFromJSON("Localizations_da-DK", in: Bundle(for: TranslationsBundle.self))
    }

}

[BucekJiri]

Just today I tried to update JimeZdrave project to NStack 5 and it keeps crashing on this fatalError on the app launch. Same thing for Carthage and CocoaPods. Have not figured out the reason yet. NStack 4 was working fine.

One thing to note is that the project has the localizations in a separate module as @jakobmygind pointed might cause trouble.

[jakobmygind]

@mariusc Any progress on decisions regarding this? As I see it it is a fix to piece of code that in itself is a bug (fatalError-ing in a catch block inside a throwing function), and also it allows fixing of a very present crash when running the app for the first time under certain circumstances. Also it is a PR towards a feature branch, so it should pose little risk.

[mariusc]

Yup, let's get this in the spm-support branch for now and see how that goes 😄

[jakobmygind]

@mariusc Cheers, buddy 👍🏻