Why not enum?

I may be wrong in this particular case, but I am always sceptical about catch statement with such a broad scope. We do not always want to catch everything. Scope of errors that should be resolved with actions taken inside this catch statement might be quite narrow. If something else throws we will ignore it, take wrong steps to resolve it and make debugging much harder. If possible then please, specify most narrow class of errors that we want to resolve by actions implemented below.

Looks like this if statement results in the same action as previous. Perhaps they could be merged? If the reason those if statements are not merged is that we want to log databaseManagerStatusValue then we can keep the separate but call same private method inside. (that is one possible solution).

Two reasons:

• we need to store string values inside Secore Store - see SecureStore::set declarations
• I want to make those strings meaningful, not 1, 2, 3... (probably we will need to check what's inside the secure store from JS side)

And as I know there is no need to do that with enums in c++: The values of the constants are values of an integral type known as the underlying type of the enumeration. (docs). And for me having 3 well-defined string constants it's more readable than e.g map and some sort of mapping int -> string which will make adding, reading, and comparing values more complex.

Overall I agree with you, but I am somewhat skeptical.
My intention was to make the process of creating and migrating database reliable for the user. I don't think letting throwing exceptions and probably killing the app (but without our knowledge and data in secure store) will be better. This method will be called from native code at the very begging of app launch.

If we will narrow the scope there will be an error that will not expect, which will be continuously thrown - user will try to open the app and get the app killed or malformed schema and we will not have tools to fix that by deleting the database and creating a new one.

If the reason those if statements are not merged is that we want to log databaseManagerStatusValue

whoops this is the log after debugging, I will remove it, sorry

Your statement is solid, but on the other hand we loose an opportunity to receive meaningful crash log with detailed stack trace, that would allow us to find and fix the error at its origin. The best solution here is to enable on the C++ side something similar to if(__DEV__ || isStaffUser(...)) that we use in JS. We could decide whether to catch or propagate exception based on whether we are running a DEV build or user is a staff member. If you agree, please create a task before landing and link it in a comment under this differential.

Shouldn't we return here? This if statement executes when databaseManagerStatus doesn't have value, but we proceed with the code that tries to access it afterwards.

We should probably return here as well. Additionally can't we merge those if statements? !databaseManagerStatus.hasValue() || databaseManagerStatus.value() == .. ?