You might learn something if you separate your else to have clauses for both false and nil as well as the existing code for a general catch. The dialyzer errors might point you to a more specific problem. Right now it seems to think that the only possible value for error is false, and I donāt see how that can be the case since your various database access should also be able to fail.
This is a Dialyzer warning that points to potentially āunreachableā code. If youāre sure that this can be nil, then maybe Dialyzer is warning here either because SystemSettings.ldap_params() has a spec but doesnāt have nil in return type, or because it is being run in a mix environment in which nil can never be returned by that function (e.g. in test and thereās always some value returned in that mix env). If this is the latter, then it can be probably safely ignored.
That makes some sense, but I would expect different wording in the error if ldap_params couldnāt return nil, because all those other matches should still be capable of failing. Or there should be more errors reporting that for example The test {:error, :couldnt_open_ldap} == nil can never evaluate to true. There appear to be 4 matches that should return something other than false or nil, and those should still cause some kind of error. The reported error by itself doesnāt make sense.
Unless @VincentBlackdot was only mystified by this one error and didnāt tell us about other ones on the same line. In which case your explanation is entirely plausible.